Comparing this a bit with Postgres-XL, how mindful of data locality do I have to be when querying? Looks like this drops right in for existing apps, but I'd be concerned about long-term performance if I didn't tailor my app code.
You don't need to worry much about data locality with pg_shard. It's designed to push the computation to the data, and as such, abstracts away most data locality concerns. The only exceptions are complex analytic workloads such as distributed joins; and CitusDB offers an easy upgrade path to remove those concerns.
Another difference with Postgres-XL is that pg_shard is an extension to PostgreSQL, rather than a separate product with different components. As such, you can just compile and load it into standard Postgres, and you're ready to go.
Comments
Comparing this a bit with Postgres-XL, how mindful of data locality do I have to be when querying? Looks like this drops right in for existing apps, but I'd be concerned about long-term performance if I didn't tailor my app code.
You don't need to worry much about data locality with pg_shard. It's designed to push the computation to the data, and as such, abstracts away most data locality concerns. The only exceptions are complex analytic workloads such as distributed joins; and CitusDB offers an easy upgrade path to remove those concerns.
Another difference with Postgres-XL is that pg_shard is an extension to PostgreSQL, rather than a separate product with different components. As such, you can just compile and load it into standard Postgres, and you're ready to go.