ServiceNow MariaDB: Architecture, Data Access, Performance and Migration Guide

Introduction

ServiceNow MariaDB refers to the MariaDB relational database technology used as an underlying database for ServiceNow instances, particularly in earlier and self-hosted ServiceNow architectures. Understanding this database layer is useful for ServiceNow developers and administrators because application tables, indexes, transactions, configuration data, and platform records ultimately depend on database operations. However, a critical point for modern implementations is that MariaDB is no longer the only database technology used by the ServiceNow platform. ServiceNow’s current architecture includes RaptorDB, with RaptorDB Standard described as the target-state default primary database, while MariaDB continues to exist in some environments.

For a typical ServiceNow application developer, the database engine is intentionally abstracted. Developers normally work through ServiceNow platform capabilities such as GlideRecord, GlideQuery, REST APIs, Scripted REST APIs, Import Sets, Transform Maps, Flow Designer, and IntegrationHub, rather than connecting directly to the underlying database.

This distinction becomes especially important when troubleshooting performance, designing integrations, understanding indexes, or supporting a ServiceNow self-hosted environment.

Current-state note: ServiceNow’s Australia documentation states that RaptorDB Standard is the target-state default primary database, while RaptorDB Professional provides additional capabilities for high-scale workloads. MariaDB and Oracle are still identified as underlying RDBMS options in parts of the platform documentation.

What Is MariaDB in ServiceNow?

MariaDB is an open-source relational database management system derived from the MySQL ecosystem. In ServiceNow’s architecture, it has been used as the persistence layer underneath the application platform.

A simplified architecture looks like this:

Users / External Systems
          |
          v
   ServiceNow Application
          |
          v
   Platform / Glide APIs
          |
          v
    Database Layer
          |
       MariaDB

The important point is that ServiceNow is not simply a web application sitting on top of a generic MariaDB database.

The ServiceNow platform provides its own application abstraction layer.

For example, a developer might write:

var gr = new GlideRecord('incident');
gr.addQuery('priority', 1);
gr.query();

while (gr.next()) {
    gs.info(gr.number);
}

The developer is working with the ServiceNow incident table rather than writing a MariaDB SQL statement.

ServiceNow’s platform handles the underlying database interaction. A ServiceNow employee has also explained in the ServiceNow Community that developers generally do not directly interact with the underlying MariaDB structure; platform APIs such as GlideRecord translate application-level queries into the appropriate database operations.

This abstraction is fundamental to ServiceNow development.

MariaDB Versus RaptorDB in Modern ServiceNow

One of the most important concepts for someone learning ServiceNow today is not to assume that every ServiceNow instance uses MariaDB.

ServiceNow’s current Australia documentation describes RaptorDB as its newer database technology. RaptorDB is designed specifically for ServiceNow AI Platform workloads, with Standard and Professional editions.

ServiceNow states that RaptorDB Professional provides capabilities such as advanced analytics, column-store functionality, and advanced topology support.

Therefore, when discussing “ServiceNow MariaDB” today, it is better to treat it as an important architectural concept and an existing database technology, rather than assuming it is the database behind every new ServiceNow instance.

How ServiceNow Uses the Database Layer

From an implementation perspective, several major platform components depend on the database layer.

Application tables

Records such as:

• Incidents
• Problems
• Changes
• Users
• Groups
• Configuration Items
• Knowledge articles
• Catalog requests
• Tasks
• Custom application records

are represented through ServiceNow’s table model.

For example:

Task
 |
 +-- Incident
 |
 +-- Problem
 |
 +-- Change Request
 |
 +-- Catalog Task

This table inheritance model is one reason ServiceNow administrators should understand the logical data model rather than trying to treat the database like a conventional application database.

Configuration data

ServiceNow also stores configuration information describing:

• Tables
• Fields
• Dictionary definitions
• Business rules
• Client scripts
• UI policies
• ACLs
• Workflows
• Flows
• Application metadata

The database therefore contains much more than business transactions.

Indexes

Indexes are important for efficient record retrieval.

For example, if a frequently executed query filters records by a particular field, an appropriate database index can significantly improve query performance.

However, indexes should not be created casually. Current ServiceNow documentation explicitly warns that creating an index on a large table can affect performance and recommends careful planning, particularly for very large tables.

Real-World ServiceNow MariaDB Use Cases

Use Case 1: Self-Hosted ServiceNow Deployment

Consider a regulated organization that operates a self-hosted ServiceNow environment.

The architecture may include:

Load Balancer
      |
      v
ServiceNow App Node 1
ServiceNow App Node 2
      |
      v
MariaDB Database
      |
      +---- Backup
      |
      +---- Replication / HA

In this model, the infrastructure team has responsibilities that would normally be handled by the SaaS provider.

They may need to manage:

• Database servers
• Storage
• CPU and memory
• Database backups
• Database replication
• Operating system configuration
• Network latency
• Database monitoring
• Disaster recovery
• Capacity planning

ServiceNow’s self-hosted documentation has historically provided MariaDB-specific deployment guidance, including a ServiceNow-tuned my.cnf configuration.

Use Case 2: ServiceNow Performance Troubleshooting

Suppose users complain:

“Incident lists are taking 15–20 seconds to open.”

A junior administrator might immediately blame the database.

An experienced ServiceNow consultant investigates the complete execution path.

For example:

User
 |
 v
List Filter
 |
 v
Encoded Query
 |
 v
Glide / Platform Query
 |
 v
Database
 |
 v
Indexes + Data Volume
 |
 v
Result Set
 |
 v
ServiceNow UI

The problem could be:

• Poorly designed query
• Missing index
• Excessive data volume
• Large related-list queries
• Inefficient business rules
• Synchronous scripting
• Expensive ACL evaluation
• Network latency
• Database resource contention

The database is only one part of the investigation.

Use Case 3: Self-Hosted Disaster Recovery

Consider a self-hosted ServiceNow customer operating production and disaster-recovery environments.

The database team might design:

Primary Environment
       |
       v
Primary MariaDB
       |
 Replication / Backup
       |
       v
DR MariaDB
       |
       v
DR ServiceNow Application

The project needs more than database replication.

The team must validate:

1. Database consistency
2. Application configuration
3. Encryption keys
4. Integration endpoints
5. Certificates
6. MID Server connectivity
7. External dependencies
8. DNS/load-balancer configuration
9. Scheduled jobs
10. Recovery procedures

A database copy alone does not automatically constitute a complete ServiceNow disaster-recovery solution.

ServiceNow Database Architecture

A simplified logical architecture is:

                    USERS
                      |
                      v
              Load Balancer
                      |
          +-----------+-----------+
          |                       |
          v                       v
      App Node 1              App Node 2
          |                       |
          +-----------+-----------+
                      |
                      v
              ServiceNow Platform
                      |
              Glide / APIs / Engine
                      |
                      v
              Database Layer
                      |
              +-------+-------+
              |               |
           MariaDB         RaptorDB
       applicable cases   modern target state

The important architectural principle is database abstraction.

A ServiceNow developer should generally think:

“How does ServiceNow expose and manage this data?”

rather than:

“Which SQL statement should I execute against MariaDB?”

That difference separates ServiceNow platform development from conventional database development.

Can ServiceNow Developers Directly Access MariaDB?

For normal ServiceNow SaaS development, direct database access is not the standard development approach.

Instead, developers use platform-supported mechanisms.

Common approaches include:

This abstraction protects the platform from application code becoming tightly coupled to a specific database engine.

Querying Data: ServiceNow Approach

Suppose an administrator wants all critical incidents that are still open.

A ServiceNow developer can use:

var incident = new GlideRecord('incident');
incident.addQuery('priority', 1);
incident.addQuery('active', true);
incident.query();

while (incident.next()) {
    gs.info(
        incident.number + ' - ' +
        incident.short_description
    );
}

Notice that there is no MariaDB SQL.

The developer works with the ServiceNow table abstraction.

This has an important implementation advantage: platform-level code is less dependent on the physical database implementation.

Understanding Indexes in ServiceNow

Indexes are one area where database knowledge becomes particularly useful.

Suppose a custom application frequently executes:

Customer = ABC
AND
Status = Open
AND
Priority = Critical

If this query is executed thousands of times, the database may need to inspect a large number of records without an appropriate index.

A consultant should first investigate:

1. How frequently is the query executed?
2. How many records exist?
3. Which fields are used for filtering?
4. Is an index already available?
5. Is the query selective?
6. Are OR conditions involved?
7. Is the table exceptionally large?
8. Is the query generated by custom code?
9. Could the business requirement be implemented differently?

ServiceNow’s current documentation provides an Index Creator through:

All → System Definition → Tables & Columns

or through the Database Indexes related list on a table.

Important consultant rule

Do not create indexes simply because a query is slow.

First identify the actual bottleneck.

An unnecessary index increases storage and maintenance overhead and can affect write operations.

Step-by-Step: Investigating the Database Used by an Instance

A useful administration exercise is determining which RDBMS an instance uses.

Step 1 – Open Database Information

Navigate to:

All → System Diagnostics → Database → Information

ServiceNow documentation identifies this page as a way to determine the RDBMS used by an instance.

Step 2 – Identify the Database Type

Depending on the environment, the database information may identify a database such as:

• MariaDB
• RaptorDB
• Oracle

Do not assume the database type simply from the ServiceNow release.

Step 3 – Document the Result

For an enterprise implementation, document:

This information becomes useful during performance and architecture discussions.

Testing Database-Related Performance

A database performance investigation should start with a reproducible transaction.

Example

Business users report that the Incident list is slow.

Test:

1. Open the Incident list.
2. Apply the production filter.
3. Record response time.
4. Test the same query in a lower environment.
5. Compare record counts.
6. Review query behavior.
7. Check whether custom scripts execute.
8. Review relevant indexes.
9. Test with a smaller date range.
10. Repeat the test after optimization.

Expected Result

The goal is not simply:

“The page loads faster.”

A proper test should demonstrate:

• Reduced query execution time
• Lower database workload
• No functional regression
• Correct result count
• Acceptable application-node resource usage

MariaDB and ServiceNow Data Access for Reporting

Historically, organizations with self-hosted deployments sometimes had database-level access as part of their infrastructure architecture.

However, modern ServiceNow customers should distinguish this from supported application-level data access.

The current platform direction includes RaptorDB Professional SQL API, which allows read-only SQL access through ODBC/JDBC for supported RaptorDB Professional environments. ServiceNow introduced this capability in the Australia release.

This is important because it demonstrates the direction of the platform:

Old approach
External BI
    |
Database-level access
    |
MariaDB

Modern supported capability
External BI
    |
ODBC / JDBC
    |
ServiceNow SQL API
    |
RaptorDB Professional

The SQL API is read-only and is designed to let supported BI tools query ServiceNow data without traditional mass replication.

Therefore, developers should not assume that direct MariaDB access is the appropriate solution simply because they need reporting data.

Common ServiceNow MariaDB Challenges

1. Assuming every ServiceNow instance uses MariaDB

This is now an outdated assumption.

ServiceNow’s current documentation describes RaptorDB as the target-state database architecture.

Solution: Always verify the actual database technology used by the instance.

2. Treating ServiceNow like a traditional database application

A developer may attempt to solve every problem with SQL.

This is generally the wrong abstraction for normal ServiceNow application development.

Solution: Start with ServiceNow-supported APIs, query mechanisms, data models, and platform features.

3. Creating too many indexes

Indexes can improve reads but are not free.

Solution: Measure the query, understand data volume, and validate the index design before implementing it.

4. Ignoring data growth

A query that works well with 100,000 records may behave differently when the table contains tens or hundreds of millions of records.

Solution:

• Establish data-retention policies.
• Archive appropriate historical data.
• Avoid unnecessary record creation.
• Review large tables regularly.
• Monitor query performance.

5. Confusing database problems with application problems

A slow page does not automatically mean MariaDB is slow.

The actual issue may be:

• Script execution
• ACL evaluation
• UI customization
• Business rules
• Integration calls
• Large related lists
• Poor query construction

Always investigate the entire transaction.

Best Practices for ServiceNow Database Architecture

1. Use ServiceNow’s abstraction layer

Prefer:

GlideRecord
GlideQuery
REST API
SOAP API
IntegrationHub
Import Sets
Flow Designer

over database-specific development wherever supported.

2. Design queries carefully

Avoid unnecessary queries inside loops.

For example, instead of repeatedly querying the same reference data for every record, consider whether the data can be retrieved once and reused.

3. Index based on evidence

Use performance evidence before creating an index.

ServiceNow specifically notes that index construction requires database knowledge and that creating indexes on large tables can have significant performance implications.

4. Control data growth

A large ServiceNow implementation should have a formal data-management strategy.

Consider:

• Retention
• Archiving
• Cleanup
• Table growth
• Attachments
• Audit/history data
• Integration staging data

Modern RaptorDB Professional environments can also use capabilities such as Live Archive to move archived records and attachments to object storage while keeping archived data accessible.

5. Do not build custom solutions around undocumented database behavior

This is particularly important for ServiceNow.

A solution that works because of a specific physical database implementation can create upgrade and migration risk.

6. Separate application and database responsibilities

In self-hosted deployments, clearly define responsibilities among:

• ServiceNow platform team
• Application developers
• DBA team
• Infrastructure team
• Security team
• Integration team

This becomes particularly important for backup, replication, upgrades, and disaster recovery.

7. Validate the database architecture before a migration

If an organization is moving from a MariaDB-based environment toward RaptorDB, do not treat it as a simple database-engine replacement.

Review:

• Custom applications
• SQL dependencies
• Reporting integrations
• Database-level scripts
• External BI tools
• Performance assumptions
• Backup processes
• Custom indexes
• Unsupported database dependencies

MariaDB and ServiceNow Migration Considerations

Database modernization is one of the areas where ServiceNow architects need to think beyond database technology.

For example:

Existing Environment
       |
       v
ServiceNow Application
       |
       v
MariaDB
       |
       +---- Custom reporting
       +---- BI integrations
       +---- Operational processes
       +---- Backup procedures

Before moving to a different architecture, identify every dependency.

A migration assessment should include:

The biggest mistake is to focus only on the database migration while ignoring applications that indirectly depend on database behavior.

Frequently Asked Questions

Is ServiceNow based on MariaDB?

ServiceNow has used MariaDB as an underlying RDBMS in applicable environments, but current ServiceNow architecture also includes RaptorDB. ServiceNow’s Australia documentation describes RaptorDB Standard as the target-state default primary database.

Can I directly query the MariaDB database behind ServiceNow?

Normal ServiceNow SaaS development does not use direct database access as the standard application-development approach. Developers generally use ServiceNow APIs and platform data-access mechanisms. For supported RaptorDB Professional environments, ServiceNow now provides a read-only SQL API through ODBC/JDBC.

Is MariaDB knowledge useful for a ServiceNow developer?

Yes, particularly for understanding relational data, indexes, query performance, transactions, table structures, and self-hosted architecture. However, a ServiceNow developer should prioritize knowledge of the ServiceNow data model and supported platform APIs rather than relying on database-specific SQL.

Expert Consultant Tips

When working on a ServiceNow project involving MariaDB, keep these principles in mind:

1. Do not assume the database technology. Verify it.
2. Understand the logical ServiceNow data model before investigating physical tables.
3. Use ServiceNow APIs instead of database-level dependencies wherever possible.
4. Treat indexes as an architectural decision, not a quick performance fix.
5. Measure performance before and after every optimization.
6. Separate database performance problems from application scripting problems.
7. Plan data retention before tables become extremely large.
8. Document all database-level dependencies in self-hosted environments.
9. Understand RaptorDB because it is central to the current ServiceNow database direction.
10. Always validate custom solutions against the current ServiceNow release documentation.

Summary

ServiceNow MariaDB is an important concept for understanding the evolution of the ServiceNow platform and its underlying database architecture. MariaDB has been used as the database layer in applicable ServiceNow environments, particularly self-hosted deployments, while developers normally interact with data through the ServiceNow platform abstraction rather than direct SQL.

The current architecture, however, is changing. ServiceNow’s Australia documentation identifies RaptorDB Standard as the target-state default primary database, with RaptorDB Professional providing additional capabilities for high-scale analytics, column-store processing, and advanced workloads.

For a ServiceNow consultant, the practical lesson is simple: understand the database because it helps you troubleshoot performance and architecture, but build applications using the supported ServiceNow platform layer rather than coupling custom functionality to a specific underlying RDBMS.

For broader Oracle Cloud reference material, the Oracle Cloud Applications documentation is available at Oracle Cloud Applications Documentation. For Oracle Fusion Time and Labor specifically, the current documentation is available through Oracle Fusion Cloud Time and Labor documentation, including the 26A update documentation.