Community Articles
Find and share helpful community-sourced technical articles.
Labels (1)

The Apache Phoenix QueryServer (PQS) is a relatively new (early 2015) component that has been added. Previously, users of Phoenix had at least two things in common: the client was written in Java and the Phoenix client libraries were included in that client. As Phoenix continues to grow as a dominant player in the "Hadoop OLTP" space, the need to eliminate these two burdens became apparent. PQS was the solution chosen to address these problems.

PQS specifically refers to an HTTP server which can interact with a custom JDBC driver that translates JDBC API calls to HTTP requests. These components are provided by an upstream Apache project, Apache Calcite, specifically the Calcite component referred to as Avatica. Originally, the HTTP requests were JSON; however recent work (mid-2015) has also shown that serialization using Protocol Buffers is also feasible.

The excitement behind PQS is two-fold as alluded. Java-based clients now have two means of running queries: a typical JDBC client with all of the necessary dependencies and computation local (the phoenix-client jar taking 10's of megabytes in space) or using the new "thin" client which offloads the majority of computation to PQS and a very small deployment footprint (little more than an HTTP client). The bigger excitement is the RPC API implicitly exposed by PQS. With a stable RPC API, this allows clients in any language to implement their own thin-client to PQS, enabling "native" access to Phoenix.

It is important to realize that PQS is still very much a work in progress effort. While efforts are ongoing to ensure that PQS is a fully-featured, secure, well-performing, and stable system. There has not been enough effort to guarantee any of these to date (2015, likely into 2016); however, there are visible strides being made in these areas.


@Josh Elser Do you recommend sql thin client instead traditional

The script is only relevant when you want to use PQS. The only difference between it and the "normal" script is the JDBC URL. Make sure you invoke the right script for using PQS (thin) or "normal" Phoenix (thick).

@Josh Elser Thanks!


It might be worth noting that the Phoenix Query Server and its JDBC client are part of the standard Phoenix distribution. And there are no additional dependencies.

New Contributor


I'm looking for a means to direct message you. In our HDP 2.5 deployment we have enabled Phoenix Query Server, and (through following some of your other forum responses - confirmed that we can connect using Kerberos secured thin client... however, the PQS appears to be caching that connection and re-using it when connecting with a different principal and keytab. If we bounce the PQS via ambari then the subsequent first secured login seemingly becomes the cached security.


@Christopher Bridge There was a recent issue in, but this was not included in HDP- Connections by PQS to HBase are always made by the PQS principal+keytab -- the end user is always "proxied" on top of the PQS credentials.

If you have an example code which shows something happening and can describe why you think this is wrong, I'll try to take a look at it. If you are a Hortonworks customer, you can/should also reach out through support channels.

Take a Tour of the Community
Don't have an account?
Your experience may be limited. Sign in to explore more.
Version history
Last update:
‎11-03-2015 05:31 AM
Updated by:
Top Kudoed Authors
; ;