161–170 of 181 posts
I've been running my project as a business for almost four years now and I think my Postgres DB is the only thing that I haven't changed. Easily the most stable part of the stack (100% uptime on RDS since 2021/02/01).
Earlier quoted context omitted.
In other words, considering we are talking about string and unicode... There are two types of programmers, those that are wrong and those that are very wrong
lol. :) Funny but not entirely true. I had cases when we had to urgently store a firehose of data and figure out the right string encoding later. Just dumping the strings with uncertain encoding in `bytea` columns helped us there. Plus for some fields it helps with auditability f.ex. when you get raw binary-encoded telemetry from devices in the field, you should store their raw payloads _and_ the parsed data structur…
Earlier quoted context omitted.
There's advantages too: - marking some columns as NOT NULL. - referential integrity means you can't accidentally have dangling pointers to non-existant dat. - mutually exclusive columns let's the database enforce things like "at least one of A and B needs to be Nonzero, and both cannot be Nonzero at the same time. - create a type that allows only values matching a specific regex. Seriously, if you want strong typing…
The things you listed aren’t stored procedures, they are all possible to implement as check constraints. They are great, and they are fully compatible with ORMs. A stored procedure is a bit of code, stored in and executed by the database, usually written in a 1960s-era language (like PL/SQL or PL/pgSQL).
I didn't claim that they are not compatible with ORMS. I said the majority of developers have no clue just how much of value they can get out of their database using types and constraints because the only interface they have every used to the RDBMS is the ORM, and the ORM doesn't expose any of this.
I've commonly seen developers put in things like `if ((!A && B) || (A && !B)) { /* updateDbWithOneOf(A,B) */ }` in their code rather than use the constraints provided by the RDBMS.
I've been running my project as a business for almost four years now and I think my Postgres DB is the only thing that I haven't changed. Easily the most stable part of the stack (100% uptime on RDS since 2021/02/01).
How do you handle minor upgrades with 100% availability?
Earlier quoted context omitted.
I wonder what's the catch with Dgraph? Why not chose it above Neo4j? I'm asking because the graph db projects I've been involved in has all used Neo4j and it would be nice to know of a good alternative.
I want it to be as free as possible, neo4j only let’s you run a single database in non-Enterprise mode. We are building a consumer product, where the database is embedded and not centralized in a cloud, so my focus is perhaps different from most. Both neo4j and dgraph comes with additional non-compete clauses, but DGraph’s work for our use case. Subjectively I’d prefer neo4j. I have been following the company since i…
Earlier quoted context omitted.
Haaaa same here for apache age. Can you elaborate a little please
The original sponsor of the project just withdrew all resources, the state of the existing codebase is far from mature, the client I tried (python) was really shaky and the lidt goes on. As for the precarious life of graph database companies. DGraph also went though being sold recently, and OrientDB that I also liked, as acquired by SAP, only to be abandoned. Neo4j has stood its time, but the licensing doesn’t fit ou…
Having just spent the better part of two weeks integrating Apache Age for Graph data, just to realize the project is stale and a mess, don’t take this list on face value. Now hoping for better results with DGraph, but it seems that graph databases are living a precarious existence.
Came here to say this. Last time I checked, Apache Age was wildly inferior to Neo4j. So technically, it does exist and has right to be on the list, but I wouldn't recommend it for serious workloads.
Having just spent the better part of two weeks integrating Apache Age for Graph data, just to realize the project is stale and a mess, don’t take this list on face value. Now hoping for better results with DGraph, but it seems that graph databases are living a precarious existence.
If I may ask, what type of use cases are there for which a graph database is well suited? I could imagine there to be a few (that I can't think of and haven't seen). I have seen graph databases used where they didn't make sense though.
Earlier quoted context omitted.
Okay, so please enlighten us, then. Which extendable open source modern database is the new hotness?
https://en.wikipedia.org/wiki/TiDB https://en.wikipedia.org/wiki/YugabyteDB https://ydb.tech/
I love Postgres but wouldn't want to use it for everyting. Taking graph databases, for example, Postgres (via Apache AGE) stores graph data in relational tables with O(log(n)) index lookups and O(k ⋅ log(n)) traversal* Whereas a true graph database like Neo4J stores graph data in adjacency lists, which means O(1) index lookups and O() traversal. That's a massive difference in traversal complexity for most graphs. *k…