samaysharma

I was curious to learn more about how they discovered and reconstructed the rules. They explain that at: https://ludus-coriovalli.web.app/about

Non-paywall link : https://archive.is/aIaZq

I don’t know if this is a question for you or for the Supabase leadership team. But, what is the primary reason for building something “new” instead of using the tools already existing in the Postgres ecosystem like Citus or pgdog?

What are the gaps in those which you expect to solve with Vitess for Postgres?

I've seen a few Postgres clients pop-up on HN recently. A recent example is: https://news.ycombinator.com/item?id=41563100

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?

What would you say are the key benefits of using this over psql? Is it mainly table metadata and properties?

Asking because running queries, history, formatting of results etc. can be achieved by configuring psqlrc.

Yes. Columnar is integrated with pg_timeseries already.

Thank you!

It's much newer for one, so it's behind on features. But, we're working on adding new ones based on customer demand.

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.

Thank you!

Few relevant blogs on using pg_vectorize:

* 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

They did chime in on Reddit https://www.reddit.com/r/PostgreSQL/comments/1aqfnvk/comment...

Introducing Skyryse One – the world’s first production aircraft operated by a single control stick, two touchscreen displays, and powered by SkyOS.

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.

Paper has a theory for the observation that older siblings earn more than younger ones.

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.

Thanks for the feedback. We're actively working on implementing the pricing page for our website. It should be out in the next few days.

Stacks[1] are basically recipes for deploying Postgres for specific use cases. This includes extensions, Postgres configs and application deployments (example: PostgREST)

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/

We're proud to announce the general availability (GA) of Tembo Cloud, a managed Postgres service that unlocks the full power of the Postgres ecosystem.

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!

Agreed. Putting data for all your use cases in a single database is a huge deal. Having different databases for each part of the application bloats so much so easily from a cost, complexity and skill set standpoint. Also, makes it extremely hard to debug issues when you have to chart the path of data through 5 different tools.

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.

Fair feedback. We only have a free tier until now. We're rolling out pricing and billing in the upcoming days and will launch a pricing page soon after to be explicit.

That's not really true any more.

I personally know several Postgres contributors / committers who have a very high amount of control on what projects they work on.

I don't have the data for the average age, but I was recently in a conversation around how long does it take to become a committer since getting involved in Postgres by writing code for it.

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

I haven't seen a full video but https://www.youtube.com/watch?v=WMWiFKl8K2o talking about it has quite a few pictures / snippets. This was done in Italy.

If you prefer watching a video, this is Marina talking about performing Rhythm 0 https://www.youtube.com/watch?v=xTBkbseXfOQ

We are planning to add support for "Push notifications for completed and failed jobs". That's in our roadmap listed here: https://tembo.io/blog/introducing-pg-later/#up-next

There isn't an explicit concept of priority / resource allocation between queries in Postgres.

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.

We're excited to share an implementation of Message Queues as a Postgres Extension (which we've been using in production), following best practices recommended by others around this topic. Please share any suggestions and feedback.

Nice! I like the focus on Postgres. Most ETL tools end up trying to build for a larger matrix of source and targets which limits using database specific features and optimizations. Is the CDC built primarily on top of the logical replication / logical decoding infrastructure in Postgres? If so, what are the limitations in that infrastructure which you'd like to see addressed in future Postgres versions?

Nice! Having job names and an audit log for job runs are both very useful features and go a long way in allowing people to monitor Postgres cron jobs more easily.

What's the most convenient tool you've found for Postgres?

(Samay from Citus)

This blog post is quite different than Cloudflare's old pipeline. I can think of three fundamental differences.

(1) Cloudflare's pipeline used an old version of Citus. On that version, Citus was still a proprietary database that forked from Postgres. Since then, Citus became an extension of Postgres (not a fork) and went open source.

(2) Features highlighted in this blog post weren't available in the old version of Citus. Example features are hash distribution, distributed roll-ups, and sharding by site_id and partitioning by time.

These features help in two ways: (a) They simplify the overall pipeline quite a bit. You don't need to rely on a single Postgres node and Kafka queues to do roll-ups. (b) Your end to end price-performance improves by 4-5x. You can ingest larger volumes of data through sharding + time partitioning. You can also do parallel roll-ups inside the database. Neither of these were possible back in the day.

(3) Similarly, Cloudflare outlined issues around single point of failures around Postgres / Citus: https://blog.cloudflare.com/http-analytics-for-6m-requests-p...

Postgres streaming replication and Citus' HA solutions have come a long way in the past three years. These points shouldn't be an issue in newer versions.

Overall, the database space is an exciting market, where products continuously evolve. This blog post presents a reference architecture that uses new features in Citus - that have been added in the past three years and that our customers are using today.

Part 1 of the blog post here: https://www.cybertec-postgresql.com/en/are-triggers-really-t...