Tiger Data combines PostgreSQL, time-series data and AI retrieval

Tiger Data is the company behind TimescaleDB and Tiger Cloud, with a substantial AI infrastructure contribution in PostgreSQL vector indexing. It is especially relevant when retrieval must combine semantic similarity with ordinary relational fields or time. The current distinction is between supported database capabilities and older AI tooling: the pgai repository now states that maintenance and support ended in February 2026.

01 / ProductThe company changed its name while its database products stayed distinct

The official rebrand announcement explains that Timescale became Tiger Data in June 2025. Its managed offering is Tiger Cloud; TimescaleDB remains the time-series PostgreSQL extension, and pgvectorscale retains its own name. These are one company’s related products, rather than separate companies to count as multiple AI vendors.

The pgvectorscale repository describes an extension that complements pgvector with StreamingDiskANN indexing, quantization and label-based filtering. It works within PostgreSQL rather than requiring the application to treat a separate vector database as its only retrieval option. The repository’s performance comparisons are vendor benchmarks, not measurements conducted for this blueprint.

Tiger Data’s pgvector documentation demonstrates a chatbot retrieval path with embeddings stored in PostgreSQL. That establishes the basic mechanism: an external model converts text into vectors, a database query retrieves candidates, and a model can use those passages as context. Database storage does not itself supply a trustworthy answer or select an embedding model.

02 / AudienceA strong fit when time and structured fields affect relevance

An operational knowledge application often needs more than the document with the closest wording. The result may have to match a customer’s product version, fall within an incident window and remain approved for use. Tiger Data is worth evaluating when those constraints already live in SQL and the team wants to avoid a second query system for each new retrieval feature.

The MongoDB blueprint offers a comparison for applications organized around documents and operational records rather than a PostgreSQL schema. The Pinecone blueprint offers a specialist managed-retrieval comparison. Compare the whole architecture: an existing PostgreSQL team may value shared tooling, whereas another team may prefer separating its operational database from search capacity.

A team that only needs a static document assistant should not assume time-series infrastructure is necessary. Conversely, a telemetry system does not become an AI retrieval application merely by adding a vector field. Identify the exact reader question and the data needed to answer it before choosing extensions or a managed plan.

03 / WorkflowProposed workflow: find the right incident resolution for the right time

This proposed pilot uses synthetic service incidents, runbooks and release records. An engineer asks how a previous failure was resolved. The answer should connect similar symptoms to the software version and time window, rather than recommending a retired workaround because it is described clearly.

1. 01

   Model incident context explicitly

   Store incident ID, service, software version, timestamp and approved resolution text. Preserve a direct link between each text chunk and its source record so the application can show evidence.

2. 02

   Create a supported embedding path

   Use application code or a maintained worker to generate embeddings with a chosen model. Record the model and text revision, retry failed work and make pending updates visible.

3. 03

   Start with exact SQL constraints

   Filter by the relevant service, supported version and approval status. Decide whether recency is an exclusion rule or a ranking preference before combining it with semantic similarity.

4. 04

   Compare retrieval approaches

   Evaluate pgvector alone, pgvectorscale indexing and PostgreSQL text search using the same labelled questions. Include exact error codes and old incidents whose wording closely resembles the new problem.

5. 05

   Present a traceable result

   Show the matched passage, incident date and version with any generated explanation. Ask the engineer to confirm applicability before taking an operational action.

Tiger Data’s hybrid-search tutorial illustrates how vector, keyword and temporal signals can disagree. Its fictional dataset is a teaching example, not evidence of a customer outcome. The useful lesson for this pilot is to evaluate which signal failed and why, rather than assuming that combining more ranking methods always improves relevance.

Keep the ingestion process observable. If a runbook changes while an embedding provider is unavailable, the application needs a rule for the old vector and the new source text. One proposed approach is to withhold the changed passage from generated answers until its embedding revision catches up. Another is to use exact text retrieval temporarily; either requires explicit application behavior.

The same principle applies to deletion and access. Removing a source record should have a defined effect on its chunks, embeddings and cached responses. Test that path with synthetic restricted documents. A retrieval query returning the correct nearest vector is insufficient if the user should no longer see the underlying material.

04 / PricingTiger Cloud bills configured compute and actual storage usage

The pricing page describes consumption billing for compute hours and average storage usage. Its storage illustrations assume 5× compression, described as average customer savings. Do not assume every vector or source-document dataset compresses by the illustrated ratio. Ask for the raw metering basis and estimate storage using a representative sample of the actual schema and indexes.

Replicas, I/O requirements and retention can change the estimate materially. Add embedding generation and answer-model usage separately. A small starting compute price is useful for orientation, but it does not establish the cost of a high-availability service with a large vector index and sustained ingestion.

Choose the plan according to the operational requirement rather than the AI label. A prototype can validate relevance with limited data; a production incident tool also needs recoverability and access controls. Verify which controls and support commitments are included in the selected order instead of inferring them from the availability of a SQL extension.

05 / DistinctionsThe meaningful advantage is composable retrieval within PostgreSQL

Keeping timestamps, structured filters and vectors in one query environment can make a retrieval design easier to inspect. Engineers can examine the records behind a result and compare alternate predicates using familiar SQL. The benefit depends on a clear schema: putting all context into unstructured text throws away some of the relational information that makes this approach useful.

Pgvectorscale adds an indexing choice to pgvector. Its label filtering and storage-oriented design offer specific things to measure, rather than a blanket promise to replace every specialist database. Compare build time, update behavior, recall and memory on the intended dataset, and retain the plain pgvector baseline so the extension’s actual contribution is visible.

TimescaleDB’s time-series focus can be relevant where the corpus includes ongoing incidents or machine events. However, a temporal partition is not a relevance policy. The application must still decide whether an older but authoritative procedure is preferable to a newer, less applicable one.

06 / QuestionsOlder pgai tutorials no longer establish a supported new-build path

The live pgai repository says the project has not been maintained or supported since February 2026. Its older examples remain readable, including automatic vectorization and semantic-catalog demonstrations. This blueprint does not treat those examples as a current supported managed service or recommend building a new dependency on their maintenance.

The pgvectorscale README also retains a private-beta invitation for specialized vector-optimized databases while documenting installation on ordinary services. Distinguish that invitation from the extension itself. Confirm the exact extension version, PostgreSQL compatibility and available Cloud configuration before turning a tutorial into a production plan.

Finally, measure the operational effects of sharing a database. Large indexing work and transactional queries can compete for resources. Test concurrent ingestion, retrieval and ordinary application traffic, then decide whether one PostgreSQL service remains the simpler design at the required scale.

07 / DecisionChoose the shared SQL approach for a concrete data advantage