11–20 of 21 posts
Postgres wire compatibility does not imply Postgres compatibility. I recently got bit by this, I wanted to convert a mail address database from MySQL Galera to CockroachDB, because CockroachDB was just a bit easier to deal with. Unfortunately, Cockroach only support UTF-8, and Postgres only supports LATIN1 for the database (compiled into code). I believe that there are reasons for both sides to make this choice, unfo…
Great observations around how popular and useful it is for systems to have some level of Postgres line compatibility! Thanks for doing the writeup!
One thing that's not totally clear in the comparison table is that most of these implementations are just that, databases providing an abstraction through the Postgres wire protocol over a different database architecture/parser & solution.
TimescaleDB, however, is the only one listed that is built directly on Postgres as an extension. There is no abstraction layer over some other implementation of the query parser or storage layer.
When it comes to application maintenance and developer expectations at query time, not all of these are apples-to-apples comparisons, as some of the other comments have noted.
Timescale DevRel here! Great observations around how popular and useful it is for systems to have some level of Postgres line compatibility! Thanks for doing the writeup! One thing that's not totally clear in the comparison table is that most of these implementations are just that, databases providing an abstraction through the Postgres wire protocol over a different database architecture/parser & solution. Timescale…
> It does NOT encompass the actual query language itself, let alone database semantics.
> This doesn't mean that any PostgreSQL or MySQL query will work with them since, as mentioned previously, query language and database semantics are independent of the wire protocol.
> To reiterate, the wire protocol doesn't specify anything about the query language.
> Just because a database implements the PostgreSQL wire protocol does not mean it intends to be a drop-in replacement for PostgreSQL.
> So just looking at parser support is not enough to talk about PostgreSQL query or semantic compatibility. But it is a starting point.
But I guess it wasn't clear.
Earlier quoted context omitted.
> Proprietary databases like Oracle and SQL Server find value in developing their own drivers. They don't tend to publish their wire protocol. Just to note, MS have long published the details of their wire protocol, TDS - https://docs.microsoft.com/en-us/openspecs/windows_protocols...
Thanks I should be fairer to them. Updated the post to note this.
Timescale DevRel here! Great observations around how popular and useful it is for systems to have some level of Postgres line compatibility! Thanks for doing the writeup! One thing that's not totally clear in the comparison table is that most of these implementations are just that, databases providing an abstraction through the Postgres wire protocol over a different database architecture/parser & solution. Timescale…
> databases providing an abstraction through the Postgres wire protocol
I would not call it an abstraction, if one has a full parser, analyzer, planner and execution engine. It is just a common language ;)
Postgres wire compatibility does not imply Postgres compatibility. I recently got bit by this, I wanted to convert a mail address database from MySQL Galera to CockroachDB, because CockroachDB was just a bit easier to deal with. Unfortunately, Cockroach only support UTF-8, and Postgres only supports LATIN1 for the database (compiled into code). I believe that there are reasons for both sides to make this choice, unfo…
What do you mean with postgres only supporting LATIN1?
Postgres wire compatibility does not imply Postgres compatibility. I recently got bit by this, I wanted to convert a mail address database from MySQL Galera to CockroachDB, because CockroachDB was just a bit easier to deal with. Unfortunately, Cockroach only support UTF-8, and Postgres only supports LATIN1 for the database (compiled into code). I believe that there are reasons for both sides to make this choice, unfo…
Well done. Couple of notes: - YugabyteDB is currently on Postgres 11.2 with plans to keep upgrading. - Cockroach is not pinned to any Postgres version so its compatibility is reliant on their implementation. Not a bad thing, just different than YB. - Like you said Timescale is in lockstep with latest Postgres (14 at the time of this comment) https://blog.timescale.com/blog/massive-scale-for-time-serie... - Materializ…
- Materialize is not really focused on scaling because that is not really what it is for Horizontal scalability is actually something that Materialize's underlying incremental computation engine (timely/differential dataflow) excels at. We're actively working to expose that tech in Materialize. (As in: many engineers, including me, are working on this full time; happy to answer questions!) It is too bad that you got…
Postgres wire compatibility does not imply Postgres compatibility. I recently got bit by this, I wanted to convert a mail address database from MySQL Galera to CockroachDB, because CockroachDB was just a bit easier to deal with. Unfortunately, Cockroach only support UTF-8, and Postgres only supports LATIN1 for the database (compiled into code). I believe that there are reasons for both sides to make this choice, unfo…