Which Database Is Used in Prometheus
If you ask which database is used in prometheus, the answer is its own built-in time series engine. It stores metrics on a local disk without needing an external database app. Engineers call this built-in storage engine the TSDB. It writes incoming metric numbers along with a timestamp and key-value labels. This design lets teams read and write live system metrics fast. When teams need long-term storage, they pair it with outside storage tools. How which database is used in prometheus works i
Just-in-Time Access + Database Access Proxy: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
If you ask which database is used in prometheus, the answer is its own built-in time series engine. It stores metrics on a local disk without needing an external database app.
Engineers call this built-in storage engine the TSDB. It writes incoming metric numbers along with a timestamp and key-value labels. This design lets teams read and write live system metrics fast. When teams need long-term storage, they pair it with outside storage tools.
How which database is used in prometheus works in practice
The local time series database saves data in two-hour blocks on the server disk. Each block acts like a small, self-contained database for that time window. A block holds index files, metadata, and compressed chunks of metric numbers.
When the server scrapes new metrics, it writes them to memory first. At the same time, it logs every write to a write-ahead log on disk. If the server crashes, it reads this log to restore recent data.
After two hours pass, the engine moves the memory data into a new disk block. In the background, the system merges older blocks together and deletes expired records. This process keeps disk use low and read queries fast for engineers and AI agents.
Each metric stream gets a unique label set, such as a server name or status code. The index file maps these labels to the exact disk chunks holding the numbers. When an engineer or AI agent runs a query, the index finds the data fast.
When teams add remote storage systems
The built-in storage engine works best for short-term metric tracking on a single node. It does not copy data across multiple servers on its own. If a local disk fails, you can lose the metric history on that machine.
Just-in-Time Access + Database Access Proxy: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
To keep metrics for months or years, teams set up remote write endpoints. The server sends a copy of each metric to an external time series system. Popular external options include Thanos, Cortex, Mimir, and VictoriaMetrics.
These external systems store metric blocks in cloud object storage buckets. They also merge data from many metric servers into one global view. Engineers can then query years of data from a single dashboard.
Security and operational tradeoffs for metric queries
Out of the box, the built-in database focuses on speed rather than strict user permissions. Anyone who can reach the query port can read all stored metrics and labels. Teams often put a basic web server in front to check a shared password.
Static keys and broad network roles create risks when humans or AI bots query metrics. Metric labels often hold sensitive values like customer emails, phone numbers, or internal host details. Once an engineer or script logs in with a static key, every metric is open.
Network rules and static passwords cannot check individual queries during an active session. They also fail to log which user ran a heavy query that crashed the server. Teams must track who reads metric data and mask sensitive fields like card numbers in results.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Does Prometheus use SQL or NoSQL under the hood?
It uses a custom time series engine rather than a standard SQL or NoSQL database. Users query it with a special language called PromQL instead of SQL.
How long does the built-in database keep metrics?
It keeps metrics on the local disk for a short period set by the team. After that time passes, the engine deletes the oldest data blocks to free up space.
Can I use PostgreSQL with Prometheus for long-term storage?
Yes, you can link it to PostgreSQL by adding the TimescaleDB extension and a remote adapter. This setup lets you store and read long-term metrics inside a relational database.