ACID stands for:
ATOMICITY: transactions either succeed (commit) or fail completely
CONSISTENCY: a transaction transforms the DB from one consistent state into another (since transactions are atomic, the DB is logically always in a consistent state)
ISOLATION: transactions are processed without the context of other transactions (logical one user system). Thus they are not interfering with each other
DURABILITY: changes caused by transactions are durable (that's where recovery, logging and so on comes in)
In order to ensure those properties a lot of research has been done and one can say that all basic things have been implemented. The hard part is of course efficiently implementing it, e.g. using B-Trees (or the new UB-Tree) for accessing and storing data efficiently. Logging and recovery mechanisms for ensuring durability. Locking mechanisms for isolation and also atomicity..... A database system actually offers almost the same depth as an OS, since it needs physical storage management, indexing, caching, query processing & optimization, parallel processing, distributed physical storage, distributed query processing, logging, fail safeness... So you might imagine that implementing a good DBMS is probably the work of hundred of work hours. An effort which is almost comparable with creating Linux itself...
``So you might imagine that implementing a good DBMS is probably the work of hundred of work hours''for the understatement of the year award. Perhaps it's all in your definition of ``good''. The following estimates could provide a reasonable baseline of effort for the magnitude of the ``good'' that one wanted to achieve:
IF (Good == "can parse SQL-92 and give correct results") THEN scheduled_engineering_hours = 1000; ELSE IF (Good == "would qualify engineering-wise for TPC benchmarks and could have a score greater than 0.1% of the best result, but not yet have support tools") THEN scheduled_engineering_hours = 10000;