Many developers learn databases from the application layer:

INSERT
SELECT
UPDATE
DELETE

That's enough—until traffic spikes, queries slow down, or the primary database fails at 3 AM.

To understand what's really happening, start with six database fundamentals: transactions, concurrency control, indexes, query optimization, backup and recovery, and high availability.

This guide explains what each one does and why it matters.

1. Transactions: All or Nothing

A transaction groups related operations into one logical unit.

BEGIN;

UPDATE accounts
SET balance = balance - 100
WHERE id = 1;

UPDATE accounts
SET balance = balance + 100
WHERE id = 2;

COMMIT;

If one operation fails, the transaction can roll back so the database doesn't end up in a partially updated state.

This is the Atomicity in ACID.

Rule of thumb: if several operations must succeed or fail together, put them in the same transaction.

2. Concurrency: MVCC and Locks

What happens when thousands of users read and write data simultaneously?

Databases use mechanisms such as MVCC (Multi-Version Concurrency Control) and locks to manage concurrent operations.

MVCC allows readers to access appropriate versions of data while reducing unnecessary read/write blocking. Locks handle conflicts when multiple transactions need to modify the same data.

For developers, the key questions are:

• Can reads and writes run concurrently?
• What happens when two transactions update the same row?
• What isolation level does the application need?

Understanding concurrency is essential for diagnosing database performance problems.

3. Indexes: Faster Queries, With a Cost

Consider a table with millions of users:

SELECT *
FROM users
WHERE email = 'dev@example.com';

Without a suitable index, the database may need to scan many rows.

An index can provide a much faster access path:

CREATE INDEX idx_users_email
ON users(email);

But more indexes don't always mean better database performance.

Indexes consume storage and can make INSERT and UPDATE operations more expensive.

The right question isn't:

"How many indexes should I create?"

It's:

"Which queries actually need an index?"

4. Query Optimizer and Statistics

You write SQL to describe what you want.

The query optimizer decides how to execute it.

It considers factors such as:

• Table size
• Data distribution
• Available indexes
• Estimated row counts
• Join conditions

Statistics provide the optimizer with information about the data.

If statistics become stale after major data changes, the optimizer may choose a poor execution plan.

A practical database tuning workflow is:

Refresh statistics → inspect the execution plan → find the bottleneck → then tune SQL or indexes.

This is also an important part of the GBase Database performance tuning methodology.

Don't add indexes blindly. First understand why the optimizer chose the current plan.

5. Backup and Recovery: Can You Actually Restore?

A database isn't reliable just because it works today.

You also need a plan for accidental deletion, hardware failure, or other incidents.

A practical backup strategy may include:

• Full backups
• Incremental backups
• Log archiving
• Retention policies
• Point-in-time recovery

But there's one step teams often skip:

Restore testing.

A backup that has never been restored is only an assumption.

For GBase Database, as with other enterprise database systems, backup and recovery should be evaluated against real RPO and RTO requirements.

6. High Availability: What Happens When the Primary Fails?

High availability is more than having multiple copies of data.

Common approaches include:

• Replication
• Automatic failover
• Primary-standby architectures
• Shared-storage clusters

When evaluating database HA, don't just ask:

"Does it support high availability?"

Ask:

"What happens when the primary database fails?"

How quickly is the failure detected? Is failover automatic? What happens to active connections? How much data can be lost?

These questions reveal much more than a feature checklist.

How These Fundamentals Connect

These six fundamentals are closely connected:

Transactions
     ↓
Concurrency Control
     ↓
Indexes
     ↓
Optimizer + Statistics
     ↓
Backup + Recovery
     ↓
High Availability

A slow query may look like an indexing problem but actually be caused by stale statistics.

A concurrency problem may actually come from transaction design or lock contention.

A recovery problem may not be caused by missing backups, but by never testing the restore process.

Understanding the fundamentals helps you troubleshoot the root cause, rather than treating symptoms.

What Developers Should Learn First

You don't need to become a DBA to understand databases.

Start by being able to answer six questions:

Transactions: What happens if one operation fails?

Concurrency: What happens when two users modify the same data?

Indexes: Why does this query use—or ignore—an index?

Optimizer: Why did the database choose this execution plan?

Recovery: Can we actually restore production data?

High Availability: What happens if the primary database fails?

These questions apply to almost every serious database system.

They also provide a useful way to understand GBase Database. Instead of memorizing product-specific features, start with the underlying database concepts, then learn how GBase Database implements them.

Final Takeaway

A database is much more than a place to store rows.

It manages data integrity, concurrency, query execution, recovery, and availability.

Learn these fundamentals first. Then go deeper into the database you actually use.

Whether you're working with GBase Database or another database platform, understanding what's happening under the hood will help you write better SQL, troubleshoot performance issues faster, and make better architecture decisions.