How PostgreSQL and databases can be used with blockchain.

"One of the things we talked about this week was PostgreSQL. What is PostgreSQL and what does it relate to blockchain? So why don't we talk a little bit about our plans with PostgreSQL, while explaining what PostgreSQL is?", asked Danny Luedke.

Joe Roets: "It's an enterprise relational database, open source, and I think it's the best relational database. I've used it for a long long time, and I used to be pretty well into it. I haven't had to build anything with it for quite a while myself, but I'm a big fan. It was always the fastest and most compliant SQL standard database, and it had a lot of amazing features. As to how we're looking at it and why were talking about it, we use it a lot internally of course, but we're looking to integrate with it directly and it's almost like an interchain where we're connecting blockchain to traditional products and services. This would be one of those that would be really powerful, because in the simplest form, an integration with database triggers would act much like an interchain between Dragonchain and Ethereum, where we can have a watcher and a publisher smart contract. So those would be directly applied on the trigger side, so that an event on your Dragonchain node could cause an entry or a change on the PostgreSQL side. Or something happening in your database, could trigger a call-out to your Dragonchain node, whether it's just to ledger a transaction, or to actually cause some operation to execute in a smart contract."

Danny Luedke: "Interesting! So if you did an integration like that, what's the difference between relational databases and a blockchain or a Dragonchain, and what type of data would you store on both? And what's the use case for it?"

Joe Roets: "This is a pretty pretty deep subject. It would take a lot of discussion, but basically the relational or traditional solid enterprise databases where you have immediate consistency. That is, once you write something, it's there, so if somebody else queries that same table the data is there. Versus non relational, maybe a more modern database where they're built for scaling and built for multi-threaded applications where you're splitting data across thousands of nodes, and doing some operation. Where that has eventual consistency, that's when you write something in there. Someone else might read it and it might not be there yet, but it will eventually be there. So you have to treat them in different ways. And the weird thing about it is, some people can consider blockchain to be somewhat eventually consistent, depending upon what blockchain you're talking about. Because I might write something that you might not see (yet), or I might something intended for you to never see, but for me to prove on some later date to have been written by me.

The differences between immediate consistency and eventual consistency.

• Immediate consistency is when I write something to a table, and anyone else with access to that table will see that result, as soon as the transaction is completed.
• Eventual consistency would be if I write it, and it might be on some blockchain node over here, whereas you might be operating on some other node over there, and sooner or later all of the nodes will be in sync.

Danny Luedke: "Now it sounds like I'd want the first one, immediate consistency. Why would I want to deploy something built off the second one, with eventual consistency?"

Joe Roets: "Eventual consistency is usually implemented for scaling reasons. E.g. if you're Google, and if you're crawling web pages and need to do operations, doing whatever Google does to score pages. Whether it's numbers of words, you know the simple and old algorithm, where it's just counting words right. Trying to put a lock on a row in a single database isn't scalable enough to hit the tens of millions or billions of pages that they have to do this with every day. And you know it depends on what you're doing, but anything like that, with Facebook or LinkedIn or other social networks where you have millions of people hitting data at the same time, and you have to build feeds for them, the same type of thing."

Danny Luedke: "And you can do types of risk assessments and stuff on the data prior to writing it too? Is that something else that can take place?

Joe Roets: "That's something that you can apply, and it's interesting too. From pretty early days with Dragonchain, and I don't talk about it too much because it's usually a very small audience that cares about this, but I kind of consider Dragonchain to be a a spectrum of consistency. What we call a spectrum of trust usually, but it's the same on the other side; if I own a business node, I can have immediate consistency because it is effectively centralized. I can decentralize it, but as soon as data is there, I have it, and I trust it because it's my own logic running it, right? And yet, if you are getting a feed of my data, you could accept it as soon as I write a level one business node block. You could say okay that's good enough for me. You could also decide to let me wait until we have enterprise governance at level three. Or let me wait until there's a notary at level four; somebody I trust on the outside says 'yes this really happened'. Or if it's an extremely valuable or sensitive transaction, you could say 'I'm gonna wait until at least a few billion dollars worth of hashpower is applied on Bitcoin, Ethereum or Ethereum Classic'. And you can say 'now I will accept this as good data'. We have kind of a mix on this side. Because we've seen a lot of applications where we needed something that had a little more horsepower for queries and typical things you'd build in an app.

Danny Luedke: "So as you start to look at the tie between Dragonchain and PostgreSQL, would that just be a DBA? Would we just be able to work within PostgreSQL and connecting to Dragonchain commands or?"

Joe Roets: "Yeah, I think the simplest form is the triggers that I mentioned in the beginning. There are a couple of other things that would be a little more complex. But it could be interesting because typical data, data design stuff, would be that if I have a lot of complex data with complex relationships and my old relational database from the 90s, right? You have a lot of that going on. You would want to put as much of the logic as possible or at least a lot of the logic specifically dealing with arranging the data in the database, in a stored procedure where the code is running right on top of the database, where it's tuned very effectively for what data is there, and it's modelings. And what we're wanting to do, and PostgreSQL is pretty amazing in this because they have multiple languages; they have the simplest all the way up to, I know they have Pearl, like every one of the languages that they have, but it's kind of crazy. You can write more advanced logic in the database working directly with and on top of the data. We want to tie that into blockchain, because then we can effectively say, just like our level one, because we have a hybrid architecture so that level one node can also run any language we've demonstrated shell scripts. We've demonstrated of course NodeJS, and there's some Go smart contracts out there, and we support Java and C#, and whatever else. But you can imagine if we said the same things, that you write a stored procedure in PostgreSQL, whatever language supported in PostgreSQL doesn't matter to us, and we stored that so it's provably the same, and we'll have to figure out a couple of things on how we do it effectively, but that the stored procedure would act as a smart contract inside the database. So you'd be connected to your level one business node, but it would be managed by you, with your level one, but it would be operating inside of your traditional database."

What's the advantage of having a stored procedure and a smart contract?

"It depends on where your data is. And that's when we integrate with more traditional systems, legacy systems especially. This is a pretty amazing capability, because a lot of these things will already be written. And they might just need some ledgering, or they might need a further Interchain where it might connect a Dragonchain, and also operate something on one of the other supported Interchains."

Danny Luedke: "Do you think this is gonna help adoption? Because one of the things I see is that there's hardly any enterprises out there with blockchain engineers or blockchain administrators. So there's not really a person to operate the blockchain within businesses. Do you think this is going to help with the adoption and those things?"

Joe Roets: "I would hope so and it might be somewhat of a stretch at first, because sysadmins can now use Dragonchain. You don't have to be a pure coder, if you're a script writer gluing code to pull systems together, you can write this into a smart contract. Much the same way a DBA or some other data architect could start building smart contracts, inside of their (deep inside of their) databases. So you think about big data applications, you think about any legacy systems, pretty important, pretty amazing, right?"

(Yes.)

Other traditional databases that could integrate with our blockchain solutions include:

• Oracle
• MySQL
• Microsoft SQL Server
• MongoDB
• Casandra
• Redis
• IBM Db2
• SAP HANA
• SQLite
• MariaDB
• Teradata Vantage