My former employer has been running for the last 3 years thousands of queries per second (with milliseconds response time) scanning thousands of rows in tables with a few billion rows without further issues. Combined with an additional write load of a few thousand writes per second. But it didn't use secondary indexes.

I'd say that Phoenix is not a substitute neither for Oracle (index integrity, acid, etc.. ) nor Hive (OLAP?). It leans on top of HBase, which is good doing small-to-medium size range scans over huge datasets under low latency. 

On Mon, 24 Jun 2019, 22:23 Jaanai Zhang, <> wrote:
To be honest, The stability of Phoenix is a big problem, the following is commonly behaviors :
1.  Hanging on the server side, the queries slow down, frequently OOM. These troubles are often caused by full scan, commonly we can use secondary indexes to avoid. It is important that make sure filters of where clause will not scan large ranges of the data table.
2.  Indexes data out of sync. I think there is a substantial improvement, the serval issues about this problem on the recent version.

Thinking whether it will be fine if uses Phoenix on your business scenarios. Phoenix has a lot of functions, but some functions about analytics are inefficient under massive data scenarios.

We have almost 200 clusters running Phoenix and solved many business requirements. 

   Jaanai Zhang
   Best regards!

Flavio Pompermaier <> 于2019年6月24日周一 下午5:30写道:
I also faced many stability problems with's very complicated to tune the tables in order to have decent performance for all kind of queries.
Since we need to be performant for every type of query (analytics and exploration) we use Elasticsearch + Join plugin (i.e. Siren platform [1])


On Mon, Jun 24, 2019 at 8:02 AM Hengesbach, Martin <> wrote:



we are using Phoenix in production since more than 2 years. We are quite unhappy with the reliability of Phoenix. We migrated from Oracle because of the performance (we have tables with up to 200M records, each record up to 30 MB in size, up to 10 selective columns). Phoenix is really much faster than Oracle (20 nodes cluster).


But we have problems with

·         Phoenix totally hanging, only restart helps (We were able to reduce this from daily to monthly)

·         incorrect indices, need rebuild

·         select statements not producing the expected (specified) results

·         Upserts sporadically not working without error message

·         Some not reproducible errors



We are thinking about switching to another database, but the question is: what is better (reliable and performant)?


Conclusion: With the current status of Phoenix, I would never use it again.







Von: jesse []
Gesendet: Samstag, 22. Juni 2019 20:04
Betreff: is Apache phoenix reliable enough?


and the bug:

 I had a similar very frustrating experience with Phoenix, In addition to various performance issues, you can found one of my posts about the reliability issue on the mail-list.



 just wondering others experience if you could share






FIZ Karlsruhe - Leibniz-Institut für Informationsinfrastruktur GmbH.
Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB 101892.
Geschäftsführerin: Sabine Brünger-Weilandt.
Vorsitzende des Aufsichtsrats: MinDirig'in Dr. Angelika Willms-Herget.

FIZ Karlsruhe ist zertifiziert mit dem Siegel "audit berufundfamilie".