NoSQL is entirely a buzzword and has no meaning whatsoever. Asking if they will support NoSQL is like asking if they will support about 30 different databases with completely different structures and APIs.

SQL isnt the problem here, its ACID. If you throw ACID out the window, there are a ton of things you can do to increase performance, which is the reason some of the NoSQL solutions can benchmark so well. If you are doing something with financial software, not using ACID is about as stupid as you can get (for the actual financial stuff, maybe for the blockchain where you have a bit more leeway and are only updating once every ~10 minutes anyway...)

And what about noSQL databases? Everyone says that they are faster and more scalable than SQL. Moreover MongoDB have interface in JSON, so it fits with default bitcoind interface.

BAD idea. NoSQL is only faster because it doesn't do all that ACID checking that transaction-safe RDBMS does. While it's perfectly fine for data that doesn't need to be consistent i.e. nobody's going to particularly care if half the world saw your twit #156483 and the other half only get updated to #156482 for the next 2 minutes. But for financial transaction, having inconsistent data and no referential integrity is malpractice and asking outright to be scammed.

Berkeley DB, as it's being used in the existing bitcoin client, is a perfect example of why not to use NoSQL.

The type of NoSQL the poster was talking about here appears to be the non-ACID type of which BDB is not one of...

Writing blocks to a flat file is not very ACID, and there is no attempt at something analogous to BEGIN TRANSACTION/COMMIT when updating the block chain or indices, so a failure part-way through a reorg is very likely to leave the database in an inconsistent state. Granted, both of these problems are outside of BDB and do not reflect on the strength or weakness of BDB.

I would say that bitcoin is effectively using a NoSQL "style" by not taking advantage of consistency guarantees, or of a relational model, both of which I think it would benefit from.

Writing blocks to a flat file is not very ACID, and there is no attempt at something analogous to BEGIN TRANSACTION/COMMIT when updating the block chain or indices, so a failure part-way through a reorg is very likely to leave the database in an inconsistent state. Granted, both of these problems are outside of BDB and do not reflect on the strength or weakness of BDB.

I would say that bitcoin is effectively using a NoSQL "style" by not taking advantage of consistency guarantees, or of a relational model, both of which I think it would benefit from.

Well if the BDB transaction fails, there will be no pointers to the extra crap at the end of the flat file and subsequent blocks will be added later, so all that would happen would be a bit of extra space would be wasted (in theory). Not quite ACID but not quite leaving the database in an "inconsistent" state.Anyway, I think weve overtaken this thread enough...

Without downloading the postgresql dump, can you please post the DDL for your schema here or provide just a dump of the schema.

I am very interested in creating a full data model (with ERD's, key discovery, propositions etc...) for Bitcoin using the Relational Model.After that is created, I would like to help create a transition model for existing accounting/monetary based software packages to incorporate Bitcoins....

I am willing to provide schema's for all major DBMS packages (Mysql, SQL Server, Oracle, DB2 and Postgress)

I am a DBA/modeller with 25 years experience and quite frankly do not have the time ATM to read and collate the schema from the raw code.

Big milestone reached! libbitcoin is the one of the first alternative implementations of the bitcoin protocol (along with node-bitcoin-p2p) to do full blockchain validation! Exciting milestone. It's taken me around 6 hours to download and validate the blockchain.

Here's a sample of validation times at 130k blocks in milliseconds:

112

22

97

316

0

38

407

1795

375

116

51

116

358

81

481

49

325

87

107

18

9

579

56

65

7

2329

98

25

103

8

4

291

155

147

140

185

55

87

15

31

67

12

47

28

16

12

34

92

0

Also I wrote a development statement for libbitcoin (also in the OP).

The Zen of libbitcoinReadability over speed.Beauty over convenience.Simplicity over complexity.Architected, not hacked.Flat, not nested.Explicit, not implicit.Errors should be loud.Never is better than right now.Now is better than never.Be flexible and configurable.Build houses from bricks, software from modules. Stability is god.

Beautiful is better than ugly. Readability over speed.Explicit is better than implicit. Beauty over convenience.Simple is better than complex. Simplicity over complexity.Complex is better than complicated. Architected, not hacked.Flat is better than nested. Flat, not nested.Sparse is better than dense. Explicit, not implicit.Readability counts. Errors should be loud.Special cases aren't special enough to break the rules. Never is better than right now.Although practicality beats purity. Now is better than never.Errors should never pass silently. Be flexible and configurable.Unless explicitly silenced. Build houses from bricks, software from modules. In the face of ambiguity, refuse the temptation to guess. Stability is god.There should be one-- and preferably only one --obvious way to do it.Although that way may not be obvious at first unless you're Dutch.Now is better than never.Although never is often better than *right* now.If the implementation is hard to explain, it's a bad idea.If the implementation is easy to explain, it may be a good idea.Namespaces are one honking great idea -- let's do more of those!