PlanetScale Launches Tin: A Full-Text Search Solution Built for Postgres

A New Option for Full-Text Search in Postgres

PlanetScale recently released Tin, a full-text search tool designed specifically for PostgreSQL. The announcement drew attention on Hacker News, quickly accumulating 201 upvotes and 75 comments — a clear signal of the developer community's ongoing interest in enhanced native search capabilities for Postgres.

For teams that rely on Postgres as their primary database, full-text search has always been a tricky subject. The conventional approaches are either to use Postgres's built-in tsvector/tsquery functionality, or to bring in a dedicated search engine like Elasticsearch or Meilisearch. The former has limitations in terms of features and usability, while the latter introduces additional operational overhead and data synchronization complexity. Tin is positioned squarely at this pain point.

Postgres's built-in full-text search is built on two data types: tsvector and tsquery. tsvector converts text into a lexeme vector after stemming and stop-word filtering, while tsquery is the expression used for matching. In practice, you typically need to manually create a GIN (Generalized Inverted Index) on text columns to speed up queries. While this mechanism covers the basics, it falls noticeably short of dedicated search engines when it comes to advanced features like CJK tokenization, relevance ranking (BM25, etc.), fuzzy matching, and highlighted snippets. The API is also relatively cumbersome with a steep learning curve.

What Problem Tin Is Trying to Solve

Splitting search functionality away from the primary database means development teams must maintain a separate piece of infrastructure and handle the complexity of keeping data synchronized and consistent across two systems. This increases overall system complexity and introduces the risk of data lag and inconsistency.

Tin's core idea is to give developers a more powerful full-text search experience within Postgres — or tightly integrated with it — so teams can avoid pulling in an external search engine. For a company focused on database infrastructure, PlanetScale launching this kind of tool is very much in line with its product philosophy: lower the operational burden of the data layer so teams can focus on their product rather than the underlying plumbing.

Why Double Down on Postgres

The Postgres ecosystem has been heating up in recent years, with more and more teams adopting it as their default database. Along with this trend, the community has grown increasingly vocal about "solving more problems with Postgres" — from vector search (pgvector) to message queues, and now full-text search. This reflects the growing popularity of the "Just use Postgres" philosophy, and Tin is a direct product of that movement.

The "Just use Postgres" philosophy is a backend architecture trend that advocates using Postgres's extensibility in place of additional middleware — at least until a system's scale actually demands a dedicated tool. Classic examples include: using the pgvector extension instead of dedicated vector databases like Pinecone, using pg_cron instead of Celery/Redis for scheduled tasks, and using LISTEN/NOTIFY instead of a message queue. The core advantage is reducing the operational surface area of distributed systems, at the cost of potentially hitting single-node performance ceilings at very large scales. Tin follows this same logic, attempting to bring full-text search into the Postgres ecosystem as well.

Community Interest and Discussion

The traction on Hacker News makes clear that real demand exists for a better Postgres full-text search story. The 75 comments typically orbit a few key dimensions: how it performs, what advantages it has over existing tsvector approaches, whether it requires extra infrastructure, and how it compares feature-for-feature with mature solutions like Elasticsearch.

Whether tools like this get widely adopted often comes down to the balance they strike between ease of use and feature completeness. If Tin can deliver relevance ranking and query capabilities approaching those of a dedicated search engine — while keeping the familiar Postgres experience — it has a real shot at becoming the default choice for small-to-medium-scale applications.

Practical Considerations Before Adopting Tin

For teams evaluating full-text search options, there are a few practical questions worth investigating before committing to Tin: How does index updating work, and how real-time is it? What is query performance like at scale? And how tightly coupled is it to the PlanetScale platform? Whether it can run on a self-hosted Postgres instance or is limited to PlanetScale's managed environment will directly determine how broadly applicable it is.

Relevance tuning for full-text search is an ongoing effort, and any new tool needs to prove itself in real production environments. For developers who are curious, it's worth starting with a small-scale pilot on non-critical workloads before committing to a full rollout.

Platform lock-in is a risk that comes with managed database products in general. PlanetScale itself is built on a Vitess architecture for MySQL, while Tin is a new product designed specifically for PostgreSQL — the relationship between the two, and whether Tin depends on PlanetScale-specific internals (such as a custom storage engine or proprietary APIs), is not yet fully clear. If Tin ships as a Postgres extension, it should theoretically run on any Postgres instance. If it's delivered as a standalone sidecar service or is restricted to the managed platform, its usability in self-hosted environments would be significantly limited. This deployment model is a key thing to confirm during evaluation.

Takeaway

The launch of Tin continues the industry trend of "doing more with Postgres," offering a new option for teams that don't want to maintain a separate search engine. Whether it truly simplifies full-text search in practice still needs to be validated through broader real-world use. For stacks built around Postgres, it's at least worth adding to the evaluation shortlist.

Since this article is based on limited release information, specific technical details, performance benchmarks, and usage constraints for Tin should be verified against the PlanetScale official blog.