61–70 of 126 posts
Earlier quoted context omitted.
Strictly speaking we charge for compute and storage. You can create variously-sized Gel instances and within those instances an arbitrary number of branches.
so I can have multiple free dev dbs using 1/4 compute unit?
Now there is
``` client.query(''' INSERT User { name := $name, dob := $dob } ''', name='Bob', dob=datetime.date(1984, 3, 1)) ```
I'm interested in this and Jetbrains Pycharm and VSCode and CI to catch errors in these.
``` insert(User(name='Bob', dob=datetime.date(1984, 3, 1), children=[User(name='C', dob=datetime.date(2000, 3, 1))]) ```
> PostgreSQL's query planner/optimizer is decidedly state-of-the-art Postgres's cost-based planner is good, but it's a decidedly 1980s design, predating the famous but also outdated Volcano/Cascades systems (used by Microsoft SQL Server and CockroachDB and others). So much has happened in the field of query optimization in the last 30 years, very little of which has ended up in Postgres, I think. Postgres has gotten…
Also there are now databases purpose built for specific domains. E.g. if you are building a financial ledger I would way rather be interfacing with TigerBeetle than scaffolding an application-driven ledger around Postgres. https://tigerbeetle.com/ . If I am scraping giant amounts of data I would run far away from Postgres for other databases like Amazon Redshift.
Bisecant fractal databases like HyperKlingonDB are excellent at storing bisecant fractal data, but terrible at anything else (often, just plain terrible overall due to being immature).
Co-founder here - AMA.
3 questions. How does this compare to solutions like Supabase. What stands out with Supabase is the sdk support. My current project is probably going to stay on Supabase( it's a hobbyist project regardless), but hypothetically if I was an enterprise prospect how would you pitch your solution. Do you support functions, that I could call from the client for more advanced logic that can't be done with queries ? Why not…
> PostgreSQL's query planner/optimizer is decidedly state-of-the-art Postgres's cost-based planner is good, but it's a decidedly 1980s design, predating the famous but also outdated Volcano/Cascades systems (used by Microsoft SQL Server and CockroachDB and others). So much has happened in the field of query optimization in the last 30 years, very little of which has ended up in Postgres, I think. Postgres has gotten…
Also there are now databases purpose built for specific domains. E.g. if you are building a financial ledger I would way rather be interfacing with TigerBeetle than scaffolding an application-driven ledger around Postgres. https://tigerbeetle.com/ . If I am scraping giant amounts of data I would run far away from Postgres for other databases like Amazon Redshift.
But even in the 9.4 days (~a decade ago) I was pushing Terabytes worth of analytics data daily through a manually managed Postgres cluster with a team of <=5 (so not that difficult). Since then there have been numerous improvements which make scaling beyond this level even easier (parallel query execution, better predicate push down by the query planner, and declarative partitioning to name a few). Throw something like Citus (extension) into the mix for easy access to clustering and (nearly) transparent table sharding and you can go quite far without reaching for specialized data storage solutions.
Earlier quoted context omitted.
> But at every conference we had the same conversation with developers I wonder if this will really go away or just be replaced with something else. Is it really the name "specifically" or how a lot of people work? (i.e. going by first impressions, connotations, memes, etc) > "EdgeDB? Huh, must be an edge-computing database. Are you running SQLite?" "Gel? Huh, must be for cosmetics. Is this for retail?" p.s. had no i…
Scott from Gel here. I suspect for everyone we talked to in the "So, this is a database for Edge computing?" camp there were a dozen people who thought that and just kept moving even if they were our target audience. It's hard to quantify just what the cost have having a name with such a strong connotation (which has arguably gone up and down in the hype cycle over the lifetime of EdgeDB) has been. Gel doesn't have a…
Almost every DB that starts without SQL support eventually ends up adding it back in later.
Co-founder here - AMA.
Can I write regular joins if I need to?
Do you have plans or do you already support db branching ?