Cloudflare CTO claims that it's not them
https://x.com/dok2001/status/2095538619603628388?s=46&t=ec6p...
4,887 karma · joined October 4, 2013
https://x.com/dok2001/status/2095538619603628388?s=46&t=ec6p...
What are the gaps in those which you expect to solve with Vitess for Postgres?
Also, several Postgres providers now also provide a SQL editor / runner and table visualizer in their UI.
What do Postgres users here think is the biggest missing thing in current clients? Are they too heavyweight? Too generic and don't support advanced Postgres features? Don't look modern enough? Not mobile friendly? Or is it something else?
Asking because running queries, history, formatting of results etc. can be achieved by configuring psqlrc.
We want to build it with a PostgreSQL license using existing community extensions as much as possible and build custom stuff (still permissively licensed) only when necessary.
* Doing vector search with just 2 commands https://tembo.io/blog/introducing-pg_vectorize
* Connecting Postgres to any huggingface sentence transformer https://tembo.io/blog/sentence-transformers
* Building a question answer chatbot natively on Postgres https://tembo.io/blog/tembo-rag-stack
SkyOS is our proprietary fly-by-wire and flight control system, offering a level of control and safety never seen before in general aviation. More than autopilot, SkyOS provides true full flight management, seamlessly integrating with the most intuitive flight controls ever designed.
TL;DR: Older siblings come home, get their younger siblings sick, negatively impact their development at a critical age and, as a result, make their adult labor market outcomes worse.
For examples, you can look at https://github.com/tembo-io/tembo/tree/main/tembo-operator/s...
[1] Blog about Stacks: https://tembo.io/blog/tembo-stacks-intro/
Tembo Cloud currently provides 194 Postgres extensions and 9 Tembo Stacks that make it easier to use Postgres for non-typical workloads such as vector search, ML, data warehousing, message queue, geospatial and more.
We look forward to hear your feedback!
There is the challenge of workload separation and scaling each component separately but that can be resolved by pulling out challenging workloads into their own "database" albeit on the same stack.
I personally know several Postgres contributors / committers who have a very high amount of control on what projects they work on.
So, I wrote a couple git commands like below [1] to figure out when someone was first named in a commit message vs when they made their first commit (as a committer) for the last 10 people who became committers.
The average time of involvement was ~8.9 years (just comparing month / year), with the lowest being ~6.5 years.
Obviously one could do better analysis but my goal was just to get an approximate understanding.
[1] git log --grep 'Name' --format=%cs | sort | head -1
git log --author 'Name' --format=%cs | sort | head -1
However, Postgres does that automatically for certain background processes like autovacuum, background worker etc. by allowing you to configure how fast / slow they go.
You could implicitly influence how fast / slow something goes by setting per role / database parameters and giving less resources to certain types of queries (https://www.postgresql.org/docs/15/sql-alterrole.html) or by using explicit locks + lock_timeout to create some kind of a priority.