TigerData Blog

Last summer we faced a conundrum at my company, Tiger Data, a Postgres cloud vendor whose main business is in timeseries data. We were trying to grow our business towards emerging AI-centric workloads and wanted to provide a state-of-the-art hybrid search stack in Postgres. We'd already built pgvectorscale in house with the goal of scaling semantic search beyond pgvector's main memory limitations. We just needed a scalable ranked keyword search solution too.

The problem: core Postgres doesn't provide this; the leading Postgres BM25 extension, ParadeDB, is guarded behind AGPL; developing our own extension appeared daunting. We'd need a small team of sharp engineers and 6-12 months, I figured. And we'd probably still fall short of the performance of a mature system like Parade/Tantivy.

Or would we? I'd be experimenting long enough with AI-boosted development at that point to realize that with the latest tools (Claude Code + Opus) and an experienced hand (I've been working in database systems internals for 25 years now), the old time estimates pretty much go out the window.

I told our CTO I thought I could solo the project in one quarter. This raised some eyebrows.

It did take a little more time than that (two quarters), and we got some real help from the community (amazing!) after open-sourcing the pre-release. But I'm thrilled/exhausted today to share that pg_textsearch v1.0 is freely available via open source (Postgres license), on Tiger Data cloud, and hopefully…

From my position

MySQL pros:

The MySQL docs on how the default storage engine InnoDB locks rows to support transaction isolation levels is fantastic. [1] This can help you better architect your system to avoid lock contention or understand why existing queries may be contending for locks. As far as I know Postgres does not have docs like that.

MySQL uses direct I/O so it disables the OS page cache and uses its own buffer pool instead[2]. Whereas Postgres doesn't use direct I/O so the OS page cache will duplicate pages (called the "double buffering" problem). So it is harder to estimate how large of a dataset you can keep in memory in Postgres. They are working on it though [3]

If you delete a row in MySQL and then insert another row, MySQL will look through the page for empty slots and insert there. This keeps your pages more compact. Postgres will always insert at the bottom of the page. If you have a workload that deletes often, Postgres will not be using the memory as efficiently because the pages are fragmented. You will have to run the VACUUM command to compact pages. [4]

Vitess supports MySQL[5] and not Postgres. Vitess is a system for sharding MySQL that as I understand is much more mature than the sharding options for Postgres. Obviously this GA announcement may change that.

Uber switched from MySQL to Postgres only to switch back. It's a bit old but it's worth a read. [6]

Postgres pros:

Postgres supports 3rd party extensions which allow you to add features…

Tiger Data (FKA Timescale) [ Global | 100% Remote | Multiple Roles: Eng, GTM, Support + more ]
We began in 2017 as TimescaleDB, focused on making PostgreSQL the best database for time-series data. As our customers evolved, so did we.

Today, more than 2,000 companies use our technology to power real-time analytics, agentic applications, and high-ingest operational systems. What started as a time-series database has become the fastest PostgreSQL for modern workloads. To reflect that evolution, we’re now TigerData—a name that speaks to our speed, precision, and ambition. The tiger has long been part of our culture: fast, focused, powerful. From “Tiger Time” all-hands to welcoming new hires as “tiger cubs,” it’s how we build—decisively, fearlessly, and with purpose.

This is not a reinvention: it’s a reflection of how we already serve our customers today.

TigerData is growing! Check us out: https://www.tigerdata.com/careers

Senior Platform Engineer - Postgres Specialist https://www.tigerdata.com/careers/8c701831-c4cf-4cc8-a9f0-0afa30474c08

Customer Delivery Engineer - https://www.tigerdata.com/careers/3d060bc0-1abf-446b-881e-f43416be227e

Partner Sales Manager, AWS - https://www.tigerdata.com/careers/c4980e2e-3b9e-4f97-9a2a-cf649f274548

I'd argue LLMs are getting cheaper, so it will get more feasible for LLMs to soon act on our behalf, bringing only what we're interested in.

Projects like OpenClaw and Hermes already show that this can work whether the source is RSS or simply a website the agent visits.

Even Google now envisions this, since they recently announced "information agents" (https://blog.google/products-and-platforms/products/search/search-io-2026/) that will keep working in the background.
They surely have an index they can use, but I wonder whether that's necessary? AI agents like Claude Code suggest it's possible to use simple keyword searches, without maintaining vector indexes - https://www.tigerdata.com/blog/why-cursor-is-about-to-ditch-vector-search-and-you-should-too

It could be that soon we're gonna get a fully personalized briefing on the topics that we're interested in, or maybe a new kind of feed, replacing social media.

I'm actually working on the briefing idea myself: https://briefin.com

At StackGres [1] we find Timescale to be one of the most used extensions. Timescale is quite a successful project!

StackGres is actually the first solution recommended by Timescale for self-hosting with Kubernetes operators [2].

So if you are into Kubernetes (or if not, consider it, using something like K3s [3] is quite straightforward and lightweight on resources), this is probably a great option to self-host which would avoid you all the hassle of manually doing all the setup involved for production-ready clusters.

[1] https://stackgres.io

[2] https://www.tigerdata.com/docs/get-started/choose-your-path/install-timescaledb#install-with-postgresql-kubernetes-operators

[3] https://k3s.io/