stevefan1999 3 hours ago

Projects that's using already existing that is using Postgres already should keep it in Postgres.

It is worth a try for startups if you won't mind. Try to vibe code around it and give the data model a new look. I have a prototype project that combines both tree-sitter AST and converted it to JSON, then since SurrealDB accepts JSON as native input I now get free graph lookup on the control flow and easily did ancestry analysis and finding what functions potentially calls to this segement. All of it is in SurrealDB nested graph queries and the performance is alright, but is abysmal in Postgres JSONB since JSONB does not linearize the JSON data structure.

ps: I'm building a K8S operator for deploying SurrealDB with TiKV operator integration too.

▲

hilariously 2 hours ago | parent [-]

Unless you want to build a startup specifically around that new hot database to do something very specific that's hard with other systems, do not build your startup around a hot new database.

The innovation points you spend on this should generally be spent in other areas, not seeing if someone's unproven db is your breadwinner.

▲

stevefan1999 an hour ago | parent | next [-]

Well, I'm still in a very early phase, but I'm indeed combining both Restate and SurrealDB together for a project that I'm building, where I persist the temporary state on Restate and permanent state on SurrealDB, and since both uses JSON as its lingua franca, it is pretty easy to serailize data between Restate and SurrealDB, very much so better than using MongoDB with BSON as many people would have naturally thought of what is supposed to be a better replacement than SurrealDB.

Oh, that's the reason the SurrealDB operator was here in the first place because I need the full K8S lifecycle to maintain the database state such as backing up, that is not really doable with Helm.

▲

itsezc 2 hours ago | parent | prev [-]

Your reasoning is very solid, and something I'd also consider before picking a DB.

No one should pick us because we're the new hot thing (at least I'd hope not). But at SurrealDB, we've got real enterprises in production at scale. For a lot of startups building today, having LLM/vector features, graph, auth, and the database in one place can really help you ship faster without stitching a bunch of tools together.

	▲	hilariously an hour ago \| parent [-]
		A good point, though I think most people take the stitch it together approach because they either have existing processes or proven tech (so startups make sense) - however generally picking an all in one often means that the base cases (like getting started) are awesome, but the edge cases are a razors edge (no familiarity with your product). As a former DBA I got to see the general purpose databases bolt on a lot of shitty addons, and a lot of upstarts build just enough to get the sale done (or targeting bigger customers than I) - I hope y'all can get enough polish and reliability done and grow into something I want to use in five years :)