Top 24 DBMS vs RDBMS Interview Questions & Answers (2026)

Last Updated: June 2026 | Level: Beginner to Advanced | Format: Q&A with Comparison Tables and Examples

DBMS vs RDBMS and SQL vs NoSQL are among the most fundamental database interview questions. Candidates report these appearing as "warm-up" questions at service companies (TCS, Infosys, Wipro) and as more detailed system design questions at product companies. Based on public preparation resources and candidate-reported accounts, CAP theorem and database selection rationale are commonly asked at backend SDE interviews.

---

Table of Contents

1. DBMS vs RDBMS Basics (Q1-Q8)
2. Relational Model Deep Dive (Q9-Q14)
3. RDBMS vs NoSQL (Q15-Q20)
4. Database Selection (Q21-Q24)

---

DBMS vs RDBMS Basics

Q1. What is a DBMS? What are its functions? Easy

A Database Management System (DBMS) is software that creates, maintains, and manages access to databases. It acts as an interface between users/applications and the stored data.

Core functions:

Function	Description
Data definition	Define the structure of data (schema: tables, types, constraints)
Data manipulation	Insert, update, delete, and query data
Data security	Control who can access what data (authentication, authorization)
Concurrency control	Manage simultaneous access from multiple users/applications
Backup and recovery	Protect data from loss and restore after failures
Integrity enforcement	Ensure data satisfies constraints (NOT NULL, UNIQUE, FK)
Data abstraction	Hide physical storage details from users

Examples: MySQL, PostgreSQL, Oracle, SQL Server (RDBMS); MongoDB, Redis, Cassandra (NoSQL DBMS); Microsoft Access, FoxPro (file-based DBMS, older generation).

---

Q2. What is an RDBMS? What makes it relational? Easy

A Relational Database Management System (RDBMS) stores data in tables (relations) with rows and columns, enforces relationships between tables using keys, and uses SQL for data access.

What makes it relational (Codd's 12 rules, simplified):

1. Data represented in tables (relations).
2. Relationships enforced via primary and foreign keys.
3. Data accessed via SQL (set-based, declarative language).
4. ACID transactions.
5. No duplicate rows (enforced by PK constraint).
6. Data independence (physical storage details hidden from logical schema).

Examples: MySQL, PostgreSQL, Oracle Database, Microsoft SQL Server, SQLite, MariaDB.

---

Q3. What are the differences between DBMS and RDBMS? Easy

Aspect	DBMS	RDBMS
Data storage	Any model (hierarchical, network, flat file, relational)	Tables with rows and columns
Relationships	Optional, not enforced by system	Enforced via foreign keys and referential integrity
Normalization	Not required	Supported and encouraged
Query language	Varies	SQL (standardized)
ACID compliance	Not always	Yes (typically)
Security	Basic	Role-based access control, row-level security
Examples	File system, XML databases, early flat-file systems	MySQL, PostgreSQL, Oracle, SQL Server
Redundancy	May be high	Reduced via normalization

Key statement: All RDBMS are DBMS. Not all DBMS are RDBMS.

---

Q4. What is the relational model? Who invented it? Easy

The relational model was proposed by Edgar F. Codd at IBM in 1970 in his landmark paper "A Relational Model of Data for Large Shared Data Banks."

Core concepts:

Concept	Description
Relation (Table)	A set of tuples with the same attributes
Tuple (Row)	A single record/instance
Attribute (Column)	A named property of the relation with a domain (data type)
Domain	The set of valid values for an attribute
Schema	The name of the relation and its attributes
Instance	The actual data in the relation at a point in time

Mathematical foundation: Relations are based on set theory. A relation is a subset of the Cartesian product of its attribute domains. No duplicate tuples (set property). Order of tuples does not matter. Order of attributes does not matter (addressed by name, not position).

---

Q5. What is data abstraction in DBMS? What are the three levels? Medium

Data abstraction hides implementation details from users, showing only what is needed at each level.

Three-schema architecture (ANSI-SPARC):

External Level (View)
    Users/applications see only the data they need.
    Multiple views of the same data.
    Example: HR app sees employee name and salary; payroll app sees salary and tax details.
          ↑
Conceptual Level (Logical Schema)
    How the data is logically organized (tables, columns, relationships).
    Independent of physical storage.
    Example: tables Employees(emp_id, name, dept_id, salary), Departments(dept_id, name).
          ↑
Internal Level (Physical Schema)
    How data is physically stored on disk.
    Index structures, file organization, storage blocks.
    Example: B+tree on emp_id, data stored in heap file /var/lib/mysql/employees.ibd.

Why three levels?

• Physical independence: change storage format without changing logical schema.
• Logical independence: change logical schema without changing application views (in theory; harder in practice).

---

Q6. What is SQL? What are its sub-languages? Easy

SQL (Structured Query Language) is the standard declarative language for managing data in relational databases.

SQL sub-languages:

Sub-language	Commands	Purpose
DDL (Data Definition Language)	CREATE, ALTER, DROP, TRUNCATE	Define/modify schema structure
DML (Data Manipulation Language)	SELECT, INSERT, UPDATE, DELETE	Manipulate data (read/write)
DCL (Data Control Language)	GRANT, REVOKE	Control access permissions
TCL (Transaction Control Language)	COMMIT, ROLLBACK, SAVEPOINT	Manage transactions
DQL (Data Query Language)	SELECT	Query data (sometimes separated from DML)

Examples:

-- DDL
CREATE TABLE employees (emp_id INT PRIMARY KEY, name VARCHAR(100));

-- DML
INSERT INTO employees VALUES (1, 'Alice');
SELECT * FROM employees WHERE emp_id = 1;
UPDATE employees SET name = 'Alice Smith' WHERE emp_id = 1;
DELETE FROM employees WHERE emp_id = 1;

-- DCL
GRANT SELECT ON employees TO 'hr_user'@'localhost';

-- TCL
BEGIN; UPDATE ...; COMMIT;

---

Q7. What is the difference between DELETE, TRUNCATE, and DROP? Easy

Command	Removes	Rolls back?	Triggers?	Auto-commit?	Resets auto-increment?
DELETE	Specific rows (or all with no WHERE)	Yes (can ROLLBACK)	Yes (row-level triggers fire)	No	No
TRUNCATE	All rows in table	No (or limited)	No (in most DBMS)	Yes (auto-commits)	Yes
DROP	Entire table (data + structure)	No	No	Yes	N/A (table gone)

DELETE FROM employees WHERE dept_id = 10;     -- Removes specific rows, transactional
DELETE FROM employees;                         -- Removes all rows, transactional

TRUNCATE TABLE employees;                      -- Removes all rows, faster, DDL operation

DROP TABLE employees;                          -- Removes entire table structure + data

When to use:

• DELETE: When you need to remove specific rows and may want to rollback.
• TRUNCATE: When you want to empty a table fast (no WHERE needed, no rollback needed).
• DROP: When the table is no longer needed at all.

---

Q8. What is the difference between WHERE and HAVING? Easy

Covered also in joins (Q13). Key differences:

-- WHERE: filters individual rows before any grouping
SELECT dept_id, COUNT(*) FROM employees
WHERE salary > 50000               -- Only rows where salary > 50000 are included
GROUP BY dept_id;

-- HAVING: filters groups after GROUP BY
SELECT dept_id, COUNT(*) FROM employees
GROUP BY dept_id
HAVING COUNT(*) > 5;               -- Only groups with more than 5 employees

-- Combining both:
SELECT dept_id, AVG(salary) FROM employees
WHERE hire_date > '2020-01-01'     -- Filter rows first
GROUP BY dept_id
HAVING AVG(salary) > 60000;        -- Then filter groups

Rule: If you can filter before grouping, use WHERE (more efficient: fewer rows to group). Use HAVING only when filtering on aggregate values.

---

Relational Model Deep Dive

Q9. What are the different types of keys in RDBMS? Easy

Key Type	Definition	Example
Primary Key	Uniquely identifies each row; NOT NULL; only one per table	employee_id in employees table
Candidate Key	Any column/set that could serve as PK; minimal superkey	{employee_id}, {email} both are CKs
Superkey	Any set of columns that uniquely identifies rows; may have extra columns	{employee_id, name} is a superkey
Foreign Key	Column that references the PK of another table; enforces referential integrity	dept_id in employees referencing departments.dept_id
Unique Key	Enforces uniqueness; allows one NULL; multiple per table	email column with UNIQUE constraint
Composite Key	A key consisting of two or more columns	(student_id, course_id) in enrollment
Surrogate Key	Artificially generated key (not from business data); usually auto-increment	auto-increment id column
Natural Key	A key derived from business data	Aadhar number, PAN number

---

Q10. What is referential integrity? How is it enforced? Medium

Referential integrity ensures that a foreign key value in one table must match an existing primary key value in the referenced table (or be NULL).

CREATE TABLE departments (
    dept_id   INT PRIMARY KEY,
    dept_name VARCHAR(100)
);

CREATE TABLE employees (
    emp_id  INT PRIMARY KEY,
    name    VARCHAR(100),
    dept_id INT REFERENCES departments(dept_id)  -- FK constraint
);

-- Referential integrity violation attempts:
INSERT INTO employees VALUES (1, 'Alice', 99);  -- dept_id=99 does not exist -> ERROR
DELETE FROM departments WHERE dept_id = 10;     -- If employees reference dept 10 -> ERROR (default)

ON DELETE / ON UPDATE actions:

Action	Behavior
RESTRICT / NO ACTION	Reject the delete/update if referenced rows exist
CASCADE	Delete/update matching rows in child table automatically
SET NULL	Set FK to NULL in child when referenced row deleted
SET DEFAULT	Set FK to default value when referenced row deleted

CREATE TABLE employees (
    dept_id INT REFERENCES departments(dept_id)
    ON DELETE CASCADE    -- When a dept is deleted, all its employees are deleted too
    ON UPDATE CASCADE    -- When dept_id changes, it propagates to employees
);

---

Q11. What is an entity-relationship (ER) model? Medium

The ER model is a conceptual data model used to design databases visually before creating SQL tables.

Key components:

Component	Symbol (text representation)	Description
Entity	Rectangle	Real-world object (Student, Course, Employee)
Attribute	Oval	Property of an entity (Name, Age, ID)
Relationship	Diamond	Association between entities (Enrolls, Works in)
Key attribute	Oval with underline	Unique identifier attribute
Multi-valued attribute	Double oval	Attribute with multiple values (phone numbers)
Derived attribute	Dashed oval	Calculated from others (Age from DOB)
Weak entity	Double rectangle	Entity that depends on another (OrderItem depends on Order)

Cardinality ratios:

One-to-One (1:1): Employee HAS one Passport.
One-to-Many (1:N): Department HAS MANY Employees.
Many-to-Many (M:N): Students ENROLL in MANY Courses. Courses have MANY Students.

M:N relationship implementation in SQL:

-- M:N requires a junction/association table:
CREATE TABLE student_course (
    student_id INT REFERENCES students(id),
    course_id  INT REFERENCES courses(id),
    PRIMARY KEY (student_id, course_id)
);

---

Q12. What is the difference between a table and a view? Medium

Aspect	Table	View
Storage	Stores actual data on disk	Stores a query definition (no data)
Updates	INSERT/UPDATE/DELETE directly	Limited (updatable views: simple views only)
Performance	Direct access	Query executed on every access (unless materialized)
Data freshness	Always current	Always current (query runs each time)
Security	Row/column-level access	Can restrict which rows/columns users see
Definition	CREATE TABLE	CREATE VIEW

-- Create a view:
CREATE VIEW emp_engineering AS
SELECT emp_id, name, salary
FROM employees
WHERE dept_id = 10;

-- Query the view like a table:
SELECT * FROM emp_engineering WHERE salary > 50000;
-- Equivalent to:
SELECT emp_id, name, salary FROM employees WHERE dept_id = 10 AND salary > 50000;

Materialized View: A view that physically stores the query results. Must be refreshed to see new data. Fast reads, stale data risk. Used in OLAP/reporting.

---

Q13. What is a stored procedure? How does it differ from a function? Medium

Aspect	Stored Procedure	Function
Return value	0 or more values (via OUT params)	Must return exactly 1 value
Used in	Executed with CALL/EXEC	Used in SQL expressions
Side effects	Can have side effects (INSERT, UPDATE)	Should be side-effect free (pure function)
Transactions	Can include transaction control (COMMIT, ROLLBACK)	Usually cannot
Error handling	Can include TRY-CATCH blocks	Limited

-- Stored procedure:
CREATE PROCEDURE update_salary(IN emp_id INT, IN raise_pct DECIMAL(5,2))
BEGIN
    UPDATE employees
    SET salary = salary * (1 + raise_pct/100)
    WHERE employees.emp_id = emp_id;
END;

CALL update_salary(42, 10.0);  -- Give employee 42 a 10% raise

-- Function:
CREATE FUNCTION get_salary(emp_id INT) RETURNS DECIMAL(10,2)
BEGIN
    DECLARE sal DECIMAL(10,2);
    SELECT salary INTO sal FROM employees WHERE employees.emp_id = emp_id;
    RETURN sal;
END;

SELECT get_salary(42);  -- Used in SELECT
SELECT * FROM employees WHERE salary > get_salary(42);  -- Used in condition

---

Q14. What is a trigger? Give an example. Medium

A trigger is a stored procedure that executes automatically in response to a table event (INSERT, UPDATE, DELETE).

-- Audit trigger: log every salary change
CREATE TABLE salary_audit (
    emp_id INT, old_salary DECIMAL, new_salary DECIMAL, changed_at TIMESTAMP
);

CREATE TRIGGER log_salary_change
AFTER UPDATE ON employees
FOR EACH ROW
BEGIN
    IF OLD.salary <> NEW.salary THEN
        INSERT INTO salary_audit VALUES (NEW.emp_id, OLD.salary, NEW.salary, NOW());
    END IF;
END;

-- Now every UPDATE to employees.salary automatically logs to salary_audit.

Trigger timing:

Timing	Description
BEFORE INSERT/UPDATE/DELETE	Execute before the operation; can modify values or cancel
AFTER INSERT/UPDATE/DELETE	Execute after; for audit logs, cascading changes
INSTEAD OF	Replace the operation (for views that are not directly updatable)

Caution: Triggers are invisible to application code. They add database-side logic that can cause unexpected behavior, slow down writes, and make debugging harder. Use judiciously for audit, not business logic.

---

RDBMS vs NoSQL

Q15. What is a NoSQL database? What are its main types? Easy

NoSQL ("Not only SQL") databases are non-relational databases designed for specific data models, providing horizontal scalability and flexible schemas.

Main NoSQL types:

Type	Description	Examples	Best for
Document	Semi-structured documents (JSON/BSON)	MongoDB, CouchDB	User profiles, product catalogs, content
Key-Value	Simple key->value pairs, very fast	Redis, DynamoDB, Memcached	Session store, caching, leaderboards
Wide-Column	Tables with dynamic columns per row	Cassandra, HBase, Bigtable	Time-series, event logs, high-write IoT
Graph	Nodes and edges with properties	Neo4j, Amazon Neptune	Social networks, recommendations, fraud detection
Time-series	Optimized for timestamped data	InfluxDB, TimescaleDB	Metrics, monitoring, financial data
Search	Full-text search and analytics	Elasticsearch, OpenSearch	Log analysis, product search

---

Q16. What are the main differences between RDBMS and NoSQL? Medium

Aspect	RDBMS (SQL)	NoSQL
Schema	Fixed, must define before data	Flexible (schema-on-read)
Relationships	Foreign keys, JOINs	Embedded documents or application-level
ACID	Full ACID (usually)	Eventual consistency (often); some have ACID
Scalability	Vertical scaling (more powerful server)	Horizontal scaling (more servers)
Query language	SQL (standardized, powerful)	DB-specific APIs (no standard)
Joins	Native SQL JOINs	Denormalized or application-level
Transactions	Multi-table ACID	Single-document (usually) or limited multi-doc
Use case	Complex queries, relational data, consistency-critical	Scale, flexibility, specific data patterns

---

Q17. What is the CAP theorem? Hard

CAP theorem (Brewer's theorem, 2000): A distributed data store can guarantee at most TWO of these three properties simultaneously:

Property	Meaning
C (Consistency)	Every read receives the most recent write or an error (all nodes agree on data)
A (Availability)	Every request receives a non-error response (but may not be the latest data)
P (Partition tolerance)	System continues operating even when network partitions (messages lost between nodes) occur

Why you cannot have all three: Network partitions are inevitable in distributed systems. So the real choice is between C and A when a partition occurs.

System classifications:

Type	What they guarantee	Examples
CP	Consistent + Partition tolerant	MongoDB (w=majority), HBase, Zookeeper, CockroachDB
AP	Available + Partition tolerant	Cassandra, CouchDB, DynamoDB (default), DNS
CA	Consistent + Available	Traditional RDBMS (single node, no partition) -- not truly distributed

Modern nuance: PACELC (extension of CAP): Even without partition, there is a latency vs consistency trade-off (ELC). Lower latency = lower consistency (you must choose).

---

Q18. What is eventual consistency? Medium

Eventual consistency is a consistency model where:

• A system guarantees that if no new updates are made, eventually all replicas will converge to the same value.
• During convergence, different nodes may serve different (stale) values.

Timeline:

User A writes: counter = 100 (to Node 1)
  t=0: Node 1 = 100, Node 2 = 99, Node 3 = 99  (replication in progress)
  t=1: Node 1 = 100, Node 2 = 100, Node 3 = 99
  t=2: Node 1 = 100, Node 2 = 100, Node 3 = 100  (converged)

When it is acceptable:

• Social media likes/view counts (stale for milliseconds is fine).
• DNS (cache propagation takes time; fine for most URLs).
• Product recommendations (slightly stale = no harm).

When it is NOT acceptable:

• Bank balance (must be strongly consistent: every read sees latest commit).
• Inventory: if 1 item remains and 2 users buy simultaneously with eventual consistency, both could "succeed."

Cassandra's consistency: Configurable per-query via consistency level. QUORUM reads and writes give strong consistency for practical purposes; ONE gives eventual consistency with better performance.

---

Q19. What is ACID vs BASE? Easy

ACID (traditional RDBMS):

• Atomicity: all or nothing.
• Consistency: valid state always.
• Isolation: concurrent transactions do not interfere.
• Durability: committed data survives failures.

BASE (many NoSQL systems):

• Basically Available: system guarantees availability (with possible stale data).
• Soft state: system state may change over time even without input (due to replication convergence).
• Eventually consistent: data will become consistent eventually.

Analogy: ACID = Bank (every transaction is exact and immediate, no ambiguity). BASE = Social media like count (briefly inconsistent but eventually correct, prioritizes availability).

Are these mutually exclusive? No. Some modern distributed databases (CockroachDB, Google Spanner, YugabyteDB) offer ACID compliance across distributed nodes (using Paxos/Raft consensus), blurring the old ACID vs BASE divide.

---

Q20. What is horizontal vs vertical scaling? Easy

Aspect	Vertical Scaling (Scale Up)	Horizontal Scaling (Scale Out)
Method	Add more resources to existing server (more CPU, RAM, SSD)	Add more servers to distribute load
Limit	Physical machine limits (max ~4TB RAM, ~100 CPU cores)	Near unlimited (add as many servers as needed)
Cost	Exponentially expensive at high end	Linear cost (commodity hardware)
Downtime	Often requires restart for hardware upgrade	Add nodes without downtime
Complexity	Simple (no distributed systems issues)	Complex (data partitioning, consistency, coordination)
RDBMS fit	Good for vertical; limited for horizontal	Hard to shard relational data without losing JOINs
NoSQL fit	Supports both	Designed for horizontal

RDBMS horizontal scaling options:

• Read replicas: Scale reads by routing SELECT to replicas. Writes still go to primary.
• Sharding: Partition data across multiple DB instances by key range or hash. Complicates cross-shard JOINs.
• NewSQL (CockroachDB, TiDB): Full SQL, ACID, and horizontal scaling. The modern answer to this problem.

---

Database Selection

Q21. How do you choose between SQL and NoSQL for a new project? Hard

Choose SQL (RDBMS) when:

• Data is structured and relational (entities with clear relationships).
• Transactions involve multiple tables (financial operations, inventory).
• Complex queries with JOINs are required.
• Data integrity and consistency are critical.
• Schema is stable and well-understood.
• Team expertise: SQL is universal, large talent pool.

Choose NoSQL when:

• Data is document-like (JSON, variable structure per record).
• Need to scale writes horizontally to many servers.
• Workload is simple key-value or time-series.
• Schema evolves rapidly (agile development, new fields per document).
• Specific data pattern: graph traversal, full-text search, high-frequency time series.

Choose both (polyglot persistence) when:

• Different parts of the application need different stores.
• Example: PostgreSQL for financial transactions + Redis for session cache + Elasticsearch for product search.

Decision matrix:

Need	Best choice
ACID transactions across tables	PostgreSQL, MySQL
High-speed key-value cache	Redis
Flexible document storage	MongoDB
Time-series sensor data	InfluxDB, TimescaleDB
Social graph traversal	Neo4j
Massive write throughput (IoT logs)	Cassandra
Full-text product search	Elasticsearch

---

Q22. What is a NewSQL database? Hard

NewSQL databases combine the ACID properties and SQL interface of relational databases with the horizontal scalability of NoSQL.

Key features:

• Full SQL support.
• ACID transactions across distributed nodes.
• Horizontal scaling via data partitioning.
• Distributed consensus (Paxos, Raft) for consistency.

Examples:

System	Developer	Key feature
CockroachDB	Cockroach Labs	Inspired by Google Spanner; distributed SQL
TiDB	PingCAP	MySQL-compatible distributed SQL
Google Spanner	Google	External consistency; global scale; TrueTime
YugabyteDB	Yugabyte	PostgreSQL-compatible distributed SQL
VoltDB	VoltDB Inc.	In-memory ACID; extreme throughput

Trade-off vs traditional RDBMS:

• Higher write latency (consensus protocol adds round trips).
• More complex operations.
• Higher cost.
• Justified for: globally distributed applications, multi-region ACID requirements.

---

Q23. What is database partitioning? What are the strategies? Hard

Partitioning divides a large table into smaller physical pieces to improve manageability, performance, and availability.

Types:

Type	Description	Example
Horizontal (Sharding)	Rows distributed across partitions based on key	Orders 1-1M on Shard 1, 1M-2M on Shard 2
Vertical	Columns split across partitions	Frequently-accessed cols in one partition, BLOBs in another
Range partitioning	Based on value ranges of a column	Orders by month: partition per month
Hash partitioning	Hash of key determines partition	HASH(user_id) % 4 -> 4 partitions
List partitioning	Explicit list of values per partition	India orders in Partition_IN, US orders in Partition_US
Composite	Combination (e.g., range + hash)	Year range first, then hash within year

Benefits:

• Query performance: queries on a specific partition only scan that partition.
• Maintenance: archive/drop old partitions easily (delete partition vs DELETE millions of rows).
• Parallelism: parallel queries across partitions.

MySQL partition example:

CREATE TABLE orders (
    order_id INT,
    order_date DATE,
    amount DECIMAL
) PARTITION BY RANGE (YEAR(order_date)) (
    PARTITION p2022 VALUES LESS THAN (2023),
    PARTITION p2023 VALUES LESS THAN (2024),
    PARTITION p2024 VALUES LESS THAN (2025),
    PARTITION pmax  VALUES LESS THAN MAXVALUE
);

---

Q24. What are common database interview questions asked about system design? Hard

At system design level, database questions focus on trade-offs and choices, not just definitions:

Common system design + database questions:

1. "Design the database for an e-commerce platform like Amazon." Expected: tables for Users, Products, Orders, OrderItems, Inventory, Payments, Reviews, Addresses. Discuss normalization, indexes on order_date, product_id, user_id. Consider partitioning Orders by date.

2. "How would you handle 1 billion rows in a users table?" Expected: sharding by user_id hash, read replicas for scaling reads, cache layer (Redis) for hot user records, archiving old/inactive users.

3. "Should you use SQL or NoSQL for a real-time leaderboard?" Expected: Redis Sorted Sets (ZADD/ZRANK) for O(log n) leaderboard operations. No SQL needed.

4. "How do you prevent duplicate payments?" Expected: idempotency key (unique transaction ID in payments table with UNIQUE constraint). Retry with same key is idempotent.

5. "Your database is slow. Where do you start?" Expected: EXPLAIN plan, check for missing indexes, check for N+1 queries, check slow query log, check buffer pool hit rate, check connection pool exhaustion.

PapersAdda tip: For every technology choice in system design, articulate the WHY. "I chose PostgreSQL because we need ACID transactions for payments and the relational schema maps well to our order-line-item structure. We'd add Redis for session caching to reduce DB load on hot paths."

---

FAQ

Q: Is MongoDB ACID compliant? MongoDB has supported multi-document ACID transactions since version 4.0 (released 2018). Before that, only single-document operations were atomic. As of 4.0+, it is ACID-compliant for multi-document transactions, though with some performance trade-offs compared to single-document operations.

Q: What is the difference between a database and a schema in MySQL? In MySQL, DATABASE and SCHEMA are synonymous. CREATE DATABASE myapp and CREATE SCHEMA myapp do the same thing. In PostgreSQL, a database contains schemas, and schemas contain tables (an extra level of namespace).

Q: Can you do JOINs in NoSQL? Not in the traditional SQL way. NoSQL databases handle relationships by: (a) embedding related documents (denormalization), (b) application-level joins (fetch both documents, join in code), or (c) some NoSQL databases (MongoDB since 3.2) support $lookup (a limited LEFT OUTER JOIN equivalent).

---

Related PapersAdda guides:

• DBMS Interview Questions 2026
• DBMS Normalization Questions 2026
• DBMS ACID Transactions Questions 2026
• System Design Interview 2026
• OS Interview Questions 2026