서버와 클라이언트는 필연적으로 데이터를 주고 받는다. 어떤 데이터는 서버에 저장해두고, 클라이언트가 요청할 때 마다 그것을 꺼내주거나, 수정하기도 하고, 새로운 데이터 공간에 창출된 데이터를 저장하거나, 지우기도 한다. 모든 정보가 저장될 필요는 없다. 그러나 어떤 정보는 반드시 저장되어야 한다. 가령 유저의 닉네임과 패스워드는 클라이언트로 하여금 서버의 감춰진 특정 정보에 접근하게 하거나, 또는 그렇지 못하게 만들기 위해 필요하다. 또 클라이언트 요청을 처리하기 위해 서버의 데이터를 활용하기도 한다. 개발자는 반드시 저장이 필요한 정보를 웹 서버(Web server)에 저장하고, 웹 서버는 웹 어플리케이션 서버(Web Application Server)로 필요한 정보를 보내 연산한 뒤 결과물을 송신한다. 서버의 리소스는 한정적이므로, 서버를 둘 이상으로 나누어 다른 역할을 부여하기도 한다. 같은 이유로 데이터를 어떻게 저장할 것인지를 정의하는 것은 리소스를 효율적으로 사용하기 위해 중요한 요소이다. 같거나, 기능적으로 유사한 정보를 중복 저장하는 경우는 없어야하고, 필요하지 않은 정보는 제거해야한다. 데이터를 검색하는 방식에 있어서도 마찬가지일 것이다. 가령 모든 데이터를 처음부터 하나씩 비교하는 것도 가능하지만, 데이터 그룹을 나누어 저장한다면 그루핑을 하기 위한 기준이 곧 데이터 검색을 위한 주소로 기능할 수도 있을 것이다.
SQL(Structured Query Language)이란 관계형 데이터베이스 시스템(RDBS, Relational DataBase System)을 처리하기 위한 언어이다. 데이터베이스가 서버가 보유한 데이터의 집합이라면, 관계형 데이터베이스는 데이터를 어떤 양식으로 묶을지에 대하여 가리키고 있다. 관계형 데이터베이스의 특징 중 하나는 데이터가 테이블에 저장된다는 것이다. 테이블은 특정한 정보들을 양식에 맞게 받아 저장한다. 예를 들어 User 테이블이 있을 수 있겠다. 개발자는 목적에 따라 몇 가지 데이터를 묶어 User 테이블에 저장할 것이다. 단, 테이블에 저장되는 최소 단위의 데이터 그룹은 타입이 반드시 고정된다. 유저의 이름, 이메일, 패스워드, 주소, 의도에 따라 어떤 타입이던 가능할 것이다. 그러나 테이블에 미리 지정한 데이터 타입이 아닌 다른 데이터, 가령 Goods라는 테이블에 들어가야 할 상품 정보 데이터 타입을 추가로 User 테이블에 저장될 수 없다(물론 기존의 유저 주소 대신 상품 정보를 저장할 수 있겠지만, 무의미할 것이다. 엄밀히 규제되는 것은 데이터의 타입이다). User 테이블이 가지고 있는 고정된 데이터 타입 집합이 정의된 것을 스키마(Schema)라고 부른다.
한 테이블에 들어갈 수 있는 데이터의 타입을 고정하는 것이 무슨 의미가 있을까? 첫 번째는 중복 데이터 저장을 억제할 수 있다는 장점이 있다. User 테이블에 저장될 정보는 다른 스키마 형태를 가지는 테이블에 저장될 수 없다(그럴 필요가 없다). 유저 정보는 오직 User 테이블에만 저장될 것이다. 유저 정보에 접근이 필요하다면, 모든 데이터를 하나하나 살펴볼 필요가 없다. 둘째, 은밀성이 필요한 정보에 대한 접근성을 정의할 수 있다. 이것은 데이터의 타입을 고정하기 때문이기보다, 테이블을 사용하여 스키마 양식을 구분함으로써 얻을 수 있는 이익일 것이다. 셋째, 개발자가 데이터 뭉치를 한눈에 보기 용이하다는 장점이 있다. 넷째, 무결성 보장을 위해 데이터 타입을 고정할 필요가 있다. 예를 들어 User 테이블에 저장되는 최소 단위의 데이터 뭉치는 유저 이름, 이메일, 패스워드 등 테이블이 요구하는 모든 데이터가 포함되어야 한다. 그들 중 하나가 빠진다면, 최소 단위의 데이터 뭉치(이하 데이터 뭉치)는 기존의 User 테이블에 저장되어 있는 데이터 뭉치 하나와 동일한 의미를 가지고 있지 못하다. 가령 유저 이름이 빠진 데이터 뭉치는 온전한 유저 데이터 뭉치와 달리 현실세계의 누구를 가리키는가에 대하여 정확한 답을 내놓지 못할 것이다.
하나의 테이블이 저장하고 있는 데이터 뭉치 내부의 정보 간 상호 연결을 통해 "나는 누구인가?"와 같은 질문에 답할 수 있다면, 데이터 뭉치 외부, 크게는 테이블 간 데이터 뭉치의 연결을 통해 "서비스 이용자의 희망에 따라 어떤 서비스를 제공해야 할 것인가?" 처럼 보다 총체적인 질문에 답할 수 있을 것이다. SQL은 테이블 간 정보의 연결(Join)의 구현을 시스템적으로 지원하고 있다. 가령 User 테이블의 한 유저와, Goods 테이블의 그 유저의 주문 상품 목록을 연결하면 복합적인 상호관계를 한 눈에 파악할 수 있을 것이다. 각각의 테이블에 관련 정보를 저장하고 이들의 관계만을 연결하는 것은 데이터 중복 저장을 억제하는 효과도 있다.
상기한 바와 같이, 관계형 데이터베이스의 가장 큰 특징 중 하나는 테이블에 저장되는 데이터 뭉치 양식을 고정하는 것, 그리고 테이블과의 연결성이라고 할 수 있다. 두 특징은 RDBS로 구현된 서버 DB를 운용할 때 상기한 여러 강점을 사용자에게 제공해주었지만, 동시에 그 경직성은 몇 가지 난점도 가지고 있다. 데이터 스키마 양식은 개발자가 정의한 시점부터 고정되어 있기 때문에, 나중에 새로운 양식을 추가하거나 제거해야 하는 경우 문제가 될 수 있다. 또 데이터간 복잡한 연결관계를 표현해야 하는 경우, 개발 난이도가 높아질 수 있을 것이다.
대체로 수직적 확장(CPU 기능 향상 등)만이 가능하고, 더 많은 서버를 추가하여 데이터를 분산시키는 확장 방식은 SQL 방식과 맞지 않을 가능성이 있다(같은 양식과 이름을 가진 두 개 이상의의 스키마가 존재하게 될 것이고, 연결관계는 더 복잡해지고, 어디서 데이터를 찾아야할 지 확정할 수 없는 등 SQL의 장점을 충분히 활용하기 어려워질 것이다). 그러나 수직적 확장은 단순히 서버 몇 대를 추가하는 것보다 더 많은 리소스를 소비한다. 성능이 좋을수록, 비슷한 수준으로 성능을 향상시키기 위해 더 큰 비용이 소비될 수 있다. NoSQL(Not Only SQL) 방식의 DB 구현은 이러한 SQL 방식의 한계를 극복하고자 비교적 최근에 제안된 구현 방식이다. NoSQL이 무엇인지, SQL과 대척점에 있는 것으로 말하기는 어려울 것이다. NoSQL은 이름 그대로 SQL의 기능을 일부 포괄하여 기능할 수 있기 때문일 것이다. 그러나 일반적으로 NoSQL의 특징이라고 하면, 스키마가 존재하지 않을 수 있다는 점(Schema-less), 그리고 연결관계(join)의 정의가 필요하지 않을 수 있다는 점일 것이다. 역설적이게도 SQL 방식의 가장 큰 장점이자 특징을 버림으로서, NoSQL은 사후에 데이터 양식의 조정이 용이하고 수직, 수평적 확장 등이 가능하다는 장점을 가지게 되었다. 스키마와 연결관계가 없는 대표적인 NoSQL중 하나로 MongoDB를 꼽을 수 있을 것이다. MongoDB는 NoSQL로서 기능을 유지하면서 스키마(Schema), 연결(Populate)과 같은 SQL 기능을 더해주는 ODM(Objective Document Mapping)인 Mongoose와 자주 사용된다.
SQL 역시 ORM(Objective Relation mapping)을 통하여 접근하기도 한다. NoSQL을 기반으로 데이터 무결성 등을 보장하기 위하여 사용되는 ODM과 ORM은 기대되는 역할이 조금 다른데, ORM은 객체 형식을 통해 여러개의 테이블로 구성된 관계형 데이터베이스를 다루는 데 도움을 준다. SQL은 SQL을 위한 별도의 쿼리문 집합을 통해 테이블을 구성하는데, 이것은 서버를 구현하기 위해 사용되는 자바, 자바스크립트, 파이썬 등과 문장 형식에 있어 차이가 존재한다. ORM은 이들 사이의 간극을 메우는 데 초점을 두고 있다. 비록 ORM으로 완전히 SQL을 대체하지 못하더라도, 객체를 통해 테이블과 연결관계를 구현하는 것은 보다 직관적이며, 가독성이 좋기에, 개발자의 생산성에 긍정적인 영향을 미칠 수 있을 것으로 기대할 수 있을 것이다.
