Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

here is a table that compares YDB to postgress

https://db-engines.com/en/system/PostgreSQL%3BYandex+Databas...

I think they wanted to have a DB that is better tuned to distributed systems. Still don't know, why they do an SQL like query language called YQL (what would that mean in practical terms? Could a common ORM framework like JPA deal with the YQL query language ?)



If that comparison table is right about "no foreign keys," that's a showstopper for me. :(

Back to looking at Couchbase, Yugabase, or Citus for my distributed SQL.


Try looking at cockroachDB, the only thing holding me back on that is the absence of triggers.


It was a brain fart: Meant to say CockroachDB instead of CouchBase. Oops.

So yeah, it's on my short list. :) I've used triggers in one project recently, but that was literally the first time in five years so it's not as much of a must-have for me.


I guess its depends, for many use cases, it can be managed at application level. I've parted ways with FK for a long time since it created more hassles than it solved esp when it comes to sharding and replications.


You can always handle it at the application level.

The trick is that it's better to have the extra guard rails. And all of Couchbase, Yugabase, and Citus support foreign keys even with sharding and replication, so that's not an issue when the DB supports it.


I said Couchbase above but meant CockroachDB. Brain fart, but can't edit the message now. :|


that's very common in distributed databases. even traditional databases, it's very common to not have FKs on large tables, and just handle it in software. indexing billions or more of rows is non-trivial.


Foreign keys come at a cost, especially in distributed database. It's just a fact. If you can avoid them, it's great.


didn't notice that. Wow that's pretty basic...


The table is a bit outdated, we are going to fix it. To be honest, YQL is a very popular language in our company, it is successfully used for more than 7 years, but I agree that outside people want to see more standard SQL dialect.


As far as I understand, YDB is different enough from regular RDBMS's that they don't provide an ODBC/JDBC/ADO.Net driver.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: