Cơ sở dữ liệu NoSQL (tên gốc là "Non SQL" (phi SQL) hoặc "non relational" (phi quan hệ))[1] cung cấp một cơ chế để lưu trữ và truy xuất dữ liệu được mô hình hóa khác với các quan hệ bảng được sử dụng trong các cơ sở dữ liệu kiểu quan hệ. Các cơ sở dữ liệu như vậy đã tồn tại kể từ cuối những năm 1960, nhưng không được gọi là "NoSQL" cho đến khi nổi tiếng đột ngột đầu thế kỷ XXI tạo nên bởi sự cần thiết cho các công ty Web 2.0 như Facebook, Google và Amazon.com.[2][3][4] Các cơ sở dữ liệu NoSQL đang được sử dụng ngày càng nhiều trong các ứng dụng dữ liệu lớn và ứng dụng nền web thời gian thực. Các hệ thống NoSQL cũng đôi khi được gọi là "Not only SQL" (không chỉ là SQL) để nhấn mạnh rằng chúng có thể hỗ trợ các ngôn ngữ truy vấn dạng như SQL.[5][6] Nguyên nhân cho hướng tiếp cận này bao gồm: tính đơn giản trong thiết kế, mở rộng theo "chiều ngang" cho các cụm máy đơn giản hơn (là bài toán cho các cơ sở dữ liệu kiểu quan hệ),[7] và kiểm soát tính khả dụng tốt hơn. Cấu trúc dữ liệu được thiết kế cho các cơ sở dữ liệu NoSQL (ví dụ: khóa-giá trị (key-value), wide column, biểu đồ hoặc tài liệu) khác với cấu trúc dữ liệu được sử dụng mặc định trong các cơ sở dữ liệu quan hệ, khiến cho nó thao tác nhanh hơn trong NoSQL. Cơ sở dữ liệu NoSQL thích hợp với từng trường hợp cụ thể cho vấn đề mà nó phải giải quyết. Đôi khi cấu trúc dữ liệu thiết kế dưới dạng NoSQL được xem là "linh hoạt" hơn các bảng cơ sở dữ liệu kiểu quan hệ.[8] Nhiều kho lưu trữ NoSQL hy sinh tính nhất quán (trong ý nghĩa của định lý CAP) để ưu tiên cho tính sẵn có, dung lượngcủa phân vùng, và tốc độ. Rào cản đối với việc áp dụng nhiều hơn các kho lưu trữ NoSQL bao gồm việc sử dụng các ngôn ngữ truy vấn mức thấp (thay vì SQL, ví dụ như thiếu khả năng thực hiện các bảng JOIN đặc biệt), thiếu giao diện chuẩn hóa, và các khoản đầu tư rất lớn trong các cơ sở dữ liệu kiểu quan hệ hiện có.[9] Hầu hết các kho lưu trữ NoSQL thiếu các giao dịch ACID đúng nghĩa, mặc dù một vài cơ sở dữ liệu, chẳng hạn như MarkLogic, Aerospike, FairCom c-treeACE, Google Spanner (mặc dù về mặt kỹ thuật là cơ sở dữ liệu dạng NewSQL), Symas LMDB và OrientDB đã đặt điều này làm trung tâm trong thiết kế của họ. (Xem Hỗ trợ ACID và JOIN.)Thay vào đó, hầu hết các cơ sở dữ liệu NoSQL đưa ra một khái niệm "thống nhất cuối cùng" trong đó các thay đổi cơ sở dữ liệu được truyền đến tất cả các nút "cuối cùng" (thường là trong mili giây) để các truy vấn dữ liệu có thể không trả lại được dữ liệu cập nhật ngay lập tức hoặc có thể dẫn đến việc đọc dữ liệu không chính xác, một vấn đề được gọi đọc lâu (stale read).[10] Ngoài ra, một số hệ thống NoSQL có thể biểu hiện bị mất các bản ghi và các hình thức mất dữ liệu khác.[11] May mắn thay, một số hệ thống NoSQL cung cấp các khái niệm như bản ghi ghi-trước (write-ahead logging) để tránh bị mất dữ liệu.[12] Đối với xử lý giao dịch phân tán trên nhiều cơ sở dữ liệu, tính thống nhất của dữ liệu là một thử thách lớn hơn, đó là khó khăn cho cả cơ sở dữ liệu kiểu NoSQL và cả cơ sở dữ liệu kiểu quan hệ. Ngay cả cơ sở dữ liệu kiểu quan hệ hiện tại "không cho phép các ràng buộc toàn vẹn tham chiếu để nối (span) các cơ sở dữ liệu."[13] Có vài hệ thống duy trì cả giao dịch ACID và cả các tiêu chuẩn X/Open XA cho xử lý giao dịch phân tán.