{"id":3873,"date":"2026-09-17T00:31:12","date_gmt":"2026-09-16T19:01:12","guid":{"rendered":"https:\/\/www.skillovilla.com\/blogs\/sql-database-types"},"modified":"2026-09-17T00:31:34","modified_gmt":"2026-09-16T19:01:34","slug":"sql-database-types","status":"publish","type":"post","link":"https:\/\/www.skillovilla.com\/blogs\/sql-database-types","title":{"rendered":"Types of Databases in SQL: Relational, NoSQL and How to Choose"},"content":{"rendered":"

“SQL database types” gets searched for two different reasons. Some people want to know what kinds of databases exist and where SQL fits among them. Others want the data types you declare inside a table, like INT and VARCHAR. This article covers both, starting with the first, because that is the one that decides which tool you learn.<\/p>\n

The short version: SQL is a language, not a database. It is the language relational databases speak, and there are about six that matter in Indian workplaces.<\/p>\n

Relational databases: where SQL lives<\/h2>\n

A relational database stores data in tables with fixed columns, and lets you join those tables together on shared keys. That join capability is the whole point. Customer data in one table, orders in another, and one query that connects them.<\/p>\n

These are the ones you will actually meet, and what distinguishes them:<\/p>\n\n\n\n\n\n\n\n\n\n\n
Database<\/th>\nTypically used for<\/th>\nCost<\/th>\nWhere you meet it in India<\/th>\n<\/tr>\n<\/thead>\n
MySQL<\/td>\nWeb applications, small to mid analytics<\/td>\nOpen source<\/td>\nThe most common first database; most startups, most WordPress sites<\/td>\n<\/tr>\n
PostgreSQL<\/td>\nAnalytics, complex queries, geospatial<\/td>\nOpen source<\/td>\nIncreasingly the default at product companies<\/td>\n<\/tr>\n
Microsoft SQL Server<\/td>\nEnterprise reporting, Windows environments<\/td>\nLicensed<\/td>\nBanks, insurers, large enterprises<\/td>\n<\/tr>\n
Oracle<\/td>\nVery large transactional systems<\/td>\nLicensed, expensive<\/td>\nTelecom, banking, legacy enterprise<\/td>\n<\/tr>\n
SQLite<\/td>\nSingle-file local storage<\/td>\nOpen source<\/td>\nMobile apps, and practice databases while learning<\/td>\n<\/tr>\n
Snowflake or BigQuery<\/td>\nCloud data warehousing at scale<\/td>\nUsage-based<\/td>\nAnalytics teams at larger companies<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

If you are learning, start with MySQL or PostgreSQL. The core language is close to identical across all of them, so the skill transfers. What differs is a thin layer of function names and administrative syntax, and you pick that up on the job in a week.<\/p>\n

NoSQL databases: the other family<\/h2>\n

NoSQL means the database does not use the relational table model. It is a category, not a product, and it splits into four fairly different things.<\/p>\n\n\n\n\n\n\n\n\n
Type<\/th>\nHow it stores data<\/th>\nExample<\/th>\nGood for<\/th>\n<\/tr>\n<\/thead>\n
Document<\/td>\nJSON-like documents with flexible fields<\/td>\nMongoDB<\/td>\nContent, catalogues, anything with varying fields<\/td>\n<\/tr>\n
Key-value<\/td>\nA key pointing at a value<\/td>\nRedis<\/td>\nCaching, sessions, leaderboards<\/td>\n<\/tr>\n
Column-family<\/td>\nColumns grouped into families, spread across machines<\/td>\nCassandra<\/td>\nVery high write volumes, time-series<\/td>\n<\/tr>\n
Graph<\/td>\nNodes and the relationships between them<\/td>\nNeo4j<\/td>\nFraud detection, recommendations, social networks<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The honest positioning: NoSQL databases solved problems that relational databases handled badly at very large scale, particularly around flexible schemas and horizontal scaling. They did not replace SQL. Most companies run both, and most analytics still happens on the relational side, which is why SQL remains the skill that gets analysts hired.<\/p>\n

Relational versus NoSQL, decided practically<\/h2>\n\n\n\n\n\n\n\n\n\n\n
<\/th>\nRelational (SQL)<\/th>\nNoSQL<\/th>\n<\/tr>\n<\/thead>\n
Schema<\/td>\nFixed; columns defined upfront<\/td>\nFlexible; documents can differ<\/td>\n<\/tr>\n
Joins<\/td>\nBuilt in and fast<\/td>\nLimited or done in application code<\/td>\n<\/tr>\n
Scaling<\/td>\nUsually by making the server bigger<\/td>\nUsually by adding more servers<\/td>\n<\/tr>\n
Consistency<\/td>\nStrong by default<\/td>\nOften eventual, tunable<\/td>\n<\/tr>\n
Query language<\/td>\nSQL, standardised<\/td>\nVaries by product<\/td>\n<\/tr>\n
Best when<\/td>\nData has clear relationships and structure<\/td>\nData is unstructured or changes shape often<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The choice is rarely yours as an analyst. You query what the engineering team built. But understanding why they chose one explains a lot about why your data looks the way it does, and it comes up in interviews as a way to check whether you know the wider system or only your own queries.<\/p>\n

SQL data types: what goes inside a column<\/h2>\n

Now the second meaning. When you create a table, every column gets a data type that fixes what it can hold. Get these wrong and you either waste storage or corrupt your numbers.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Category<\/th>\nType<\/th>\nWhat it holds<\/th>\nExample value<\/th>\n<\/tr>\n<\/thead>\n
Numeric<\/td>\nINT<\/td>\nWhole numbers<\/td>\n4521<\/td>\n<\/tr>\n
Numeric<\/td>\nBIGINT<\/td>\nVery large whole numbers<\/td>\n9223372036854775<\/td>\n<\/tr>\n
Numeric<\/td>\nDECIMAL(p,s)<\/td>\nExact decimals, p digits with s after the point<\/td>\n58999.00<\/td>\n<\/tr>\n
Numeric<\/td>\nFLOAT<\/td>\nApproximate decimals<\/td>\n3.14159<\/td>\n<\/tr>\n
Text<\/td>\nCHAR(n)<\/td>\nFixed-length text, padded<\/td>\nIN<\/td>\n<\/tr>\n
Text<\/td>\nVARCHAR(n)<\/td>\nVariable-length text up to n<\/td>\nBengaluru<\/td>\n<\/tr>\n
Text<\/td>\nTEXT<\/td>\nLong text, no practical limit<\/td>\nA product description<\/td>\n<\/tr>\n
Date<\/td>\nDATE<\/td>\nCalendar date only<\/td>\n2026-08-16<\/td>\n<\/tr>\n
Date<\/td>\nDATETIME<\/td>\nDate and time<\/td>\n2026-08-16 14:30:00<\/td>\n<\/tr>\n
Date<\/td>\nTIMESTAMP<\/td>\nDate and time, timezone-aware<\/td>\n2026-08-16 14:30:00<\/td>\n<\/tr>\n
Other<\/td>\nBOOLEAN<\/td>\nTrue or false<\/td>\nTRUE<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Three rules that prevent most beginner mistakes. Store money as DECIMAL, never FLOAT, because floating-point arithmetic introduces rounding errors that surface as one-paisa gaps in a monthly total. Store phone numbers as VARCHAR, not INT, because a leading zero disappears from a number and a plus sign will not fit. And size VARCHAR generously; the storage cost of VARCHAR(200) over VARCHAR(50) is negligible, but the cost of a truncated address is a broken delivery.<\/p>\n

Constraints: the rules a column enforces<\/h2>\n

Alongside the data type, you can attach constraints that the database refuses to violate. These matter to analysts because they explain why your data is trustworthy in some columns and not others.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Constraint<\/th>\nWhat it enforces<\/th>\nExample use<\/th>\n<\/tr>\n<\/thead>\n
PRIMARY KEY<\/td>\nUnique and never NULL<\/td>\norder_id on an orders table<\/td>\n<\/tr>\n
FOREIGN KEY<\/td>\nValue must exist in another table<\/td>\ncustomer_id pointing at customers<\/td>\n<\/tr>\n
NOT NULL<\/td>\nA value is always required<\/td>\ncustomer_name<\/td>\n<\/tr>\n
UNIQUE<\/td>\nNo two rows share the value<\/td>\nemail address<\/td>\n<\/tr>\n
CHECK<\/td>\nValue must satisfy a condition<\/td>\namount must be greater than zero<\/td>\n<\/tr>\n
DEFAULT<\/td>\nFills a value when none is given<\/td>\nstatus defaults to pending<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

When you find orphaned records in a dataset, orders whose customer no longer exists, the reason is almost always a missing foreign key constraint. The database was never told the relationship had to hold, so nothing stopped it breaking.<\/p>\n

Cloud data warehouses: the type analysts increasingly work in<\/h2>\n

There is a fourth category worth separating out, because it is where a growing share of Indian analytics jobs actually run. Snowflake, Google BigQuery and Amazon Redshift are relational and speak SQL, but they are built for analysis rather than for running an application.<\/p>\n

The difference is how they store data. A transactional database like MySQL stores a row at a time, which is fast when you want one customer’s full record. A warehouse stores a column at a time, which is fast when you want the average of one column across fifty million rows and do not care about the other columns. That single design choice is why a query that takes four minutes on MySQL can take four seconds on BigQuery.<\/p>\n

Three practical consequences for an analyst:<\/p>\n