The short version
RaptorDB is ServiceNow's new proprietary database engine, replacing MariaDB (a MySQL fork) as the underlying data store for every ServiceNow instance. It is built on PostgreSQL and specifically optimised for ServiceNow's mixed transactional and analytical workload. You do not install it, configure it, or migrate to it manually — ServiceNow is rolling it out to all customers at the platform level, automatically.
The numbers ServiceNow is quoting: up to 27x faster reports and list views, up to 53% improvement in overall transaction times, and up to 3x more transactional throughput. Not every customer will see maximums — gains depend heavily on data volume, query complexity, and current baseline performance — but even conservative estimates represent a meaningful improvement for most production instances.
Why ServiceNow needed to replace MariaDB
For over a decade ServiceNow ran on MariaDB, a fork of MySQL. It worked. But as enterprises pushed the platform harder — with billions of records across ITSM, HRSD, CMDB, SecOps, and dozens of custom applications — the limitations started showing in predictable ways. Slow instance investigations increasingly pointed at database-level bottlenecks that could not be solved at the application layer.
The core architectural problem: relational databases like MariaDB are optimised for one thing at a time. They handle transactional workloads well — inserts, updates, individual record reads. They struggle when you need to run analytics on the same data simultaneously. A Performance Analytics collection job running while agents are actively working incidents creates contention at the database level. A complex report on a table with ten million records can cause query timeouts that affect everyone on the instance.
This is not a flaw in MariaDB — it is the fundamental trade-off of traditional RDBMS architecture. You can have fast transactions or fast analytics. Getting both simultaneously at scale requires a different approach. That approach has a name: HTAP.
HTAP — Hybrid Transactional and Analytical Processing
HTAP is an architecture that handles both transactional workloads (inserting an incident, updating a record, running a Business Rule) and analytical workloads (Performance Analytics collection, complex reports, GlideAggregate queries across millions of records) in the same database engine, on the same data, at the same time — without the transactional side slowing down the analytical side or vice versa.
RaptorDB achieves this by maintaining two representations of the same data internally: a row-store for transactional operations (the traditional format, optimised for individual record access) and a column-store for analytical operations (columns stored together, optimised for aggregations and scans). The engine routes queries to the right internal representation automatically. You write the same GlideRecord query you always wrote — RaptorDB decides how to execute it most efficiently.
What actually changed under the hood
RaptorDB is built on PostgreSQL, which ServiceNow gained access to through its 2021 acquisition of Swarm64, a Berlin-based database optimisation company that specialised in high-performance PostgreSQL extensions. PostgreSQL allows more advanced query types than MySQL/MariaDB, supports better parallel processing, and enables more sophisticated indexing strategies.
The key technical additions RaptorDB brings to ServiceNow:
- Column-store index — data stored in columnar format in addition to the traditional row format. Analytics queries that scan millions of rows reading just a few columns (COUNT, AVG, GROUP BY queries) run against the column store, which is dramatically faster for this access pattern.
- Parallel query execution — multiple CPU cores process a single query simultaneously rather than sequentially. A complex report that used to run on one core now distributes across available cores, reducing wall-clock time proportionally.
- Smarter automatic indexing — the engine analyses query patterns and suggests or creates indexes automatically on frequently accessed columns. Reduces manual index management overhead.
- Compressed storage — columnar storage uses significantly more efficient compression than row storage for typical ServiceNow data patterns, reducing storage costs at scale.
- No ETL required — transactional data and analytical data live in the same store. No nightly extract-transform-load jobs needed to move data to a separate analytics database. Performance Analytics sees changes immediately.
Two tiers: Standard and Professional
RaptorDB Standard is the default for all customers. It replaces MariaDB as the primary database engine at no additional cost. ServiceNow is migrating all existing instances automatically through their standard release process. Standard includes all the core performance improvements — HTAP, column-store indexing, parallel queries, compression.
RaptorDB Professional is a premium licensed add-on for organisations that need ultra-scale performance: AI workloads on massive datasets, real-time analytics on billions of records, machine-scale data processing. If your organisation is ingesting telemetry at a level where standard database performance is a bottleneck, Professional is the tier to evaluate. Contact your ServiceNow account team for pricing and eligibility.
What this means for developers
The honest developer answer: nothing changes in your code. Your GlideRecord queries, your Business Rules, your Flow Designer flows, your GlideAjax Script Includes — they all work exactly the same. There is no migration work, no deprecated API, no syntax change.
What you will notice in practice:
- GlideRecord queries on large tables return results faster — the column-store index helps even single-field lookups on indexed columns
- GlideAggregate operations run significantly faster — aggregations benefit most from the column-store architecture
- Encoded queries with GROUP BY patterns resolve faster
- Scripts that previously timed out on large table scans may now complete within timeout limits
The most important implication for developers: the Instance Scan findings about "GlideRecord without conditions on large tables" remain valid — RaptorDB makes unconstrained queries faster, but not infinitely so. Write efficient queries regardless.
What this means for admins
- Performance Analytics dashboards load noticeably quicker — the column-store specifically helps PA score collection and aggregation
- List views with complex filters respond faster, particularly on high-volume tables like incident, task, and cmdb_ci
- CMDB queries and relationship lookups improve significantly — CMDB tables are large and heavily queried analytically
- Report generation that previously caused timeouts may now complete within platform limits
- Discovery result processing speeds up — Discovery sensors write large volumes of CI data that RaptorDB handles more efficiently
How to check if your instance is on RaptorDB
Navigate to https://[instance].service-now.com/stats.do — the stats page shows the database engine version in the instance diagnostic information. Alternatively, navigate to System Diagnostics > Stats. New instances provisioned after ServiceNow's RaptorDB rollout are already on it. Existing instances are being migrated through 2025 and 2026 as part of ServiceNow's standard upgrade cadence.
You can also check your instance's release notes page — ServiceNow includes RaptorDB migration status in instance-specific release communications.
Performance benchmarks in context
The 27x figure for reports and list views is the maximum measured improvement in ServiceNow's internal testing, on specific query types on very large datasets. Real-world gains for most customers range from 20–75% depending on data volume, with larger instances seeing proportionally larger improvements because the column-store architecture scales better than row-store at high volumes.
ServiceNow's published benchmarks show: 26% average improvement for instances under 5 million records, 52% for mid-size instances, and up to 75% for large enterprise instances with hundreds of millions of records. For most commercial customers, the 26–52% range is realistic.
Why it will come up in interviews and client conversations
RaptorDB represents a fundamental architectural shift in the ServiceNow platform — the kind of change that happens once a decade. Any conversation about ServiceNow performance, scalability, or roadmap will reference it. If you are pursuing the CAD certification or moving toward architect-level roles, understanding the database layer distinguishes you from candidates who only know the application layer. It also directly informs recommendations you give clients about performance troubleshooting and infrastructure planning.
Also in the performance series: GlideRecord performance tips — writing efficient server-side queries · Stop using toString() — a simple change with real performance impact · Instance Scan — auditing your instance for performance anti-patterns · Troubleshoot slow instance — systematic diagnostic process
RaptorDB and the developer performance mental model
Understanding RaptorDB changes how you think about performance optimisation. Previously, when a slow instance investigation pointed at a database query, the solution was often to add an index, rewrite the query, or move the operation to a scheduled async job. RaptorDB does not eliminate the need for query hygiene — unconstrained GlideRecord queries on massive tables are still bad practice — but it raises the baseline from which optimisation is needed.
Think of it this way: if MariaDB could handle 10,000 records in an analytical query before timing out, RaptorDB might handle 50,000–100,000 before hitting the same threshold. Scripts that previously required async execution or chunking may now complete synchronously within acceptable time limits. Performance Analytics collection that previously took 20 minutes may complete in 5. This does not change what good code looks like — GlideAggregate is still the right tool for counting and aggregating, not GlideRecord loops — but it expands the headroom within which good code operates.
What RaptorDB does not change
A few things to be clear about:
- ACL performance — if your ACL scripts run GlideRecord queries inside them, those still execute on every record access. RaptorDB does not eliminate the overhead of scripted ACLs.
- Business Rule execution — Before and After rules still fire synchronously on every qualifying record update. RaptorDB makes the database side faster but does not change the application-layer execution model.
- Client-side performance — RaptorDB is a server-side database change. It does not affect browser rendering, JavaScript execution, or the round-trip time for GlideAjax calls.
- API rate limits — Table API and Scripted REST API rate limits are a ServiceNow platform policy, not a database constraint.
The Swarm64 acquisition context
ServiceNow acquired Swarm64 in 2021 for a reported $250 million. Swarm64 was a Berlin-based startup that had built a high-performance PostgreSQL extension called SDA (Swarm64 Data Accelerator) — essentially a columnar acceleration layer on top of standard PostgreSQL. The technology is the core of what became RaptorDB. The acquisition was notable for being one of the largest database infrastructure acquisitions by a SaaS platform in recent years, and it signalled ServiceNow's intent to own its database stack rather than depending on commodity open-source solutions.