<p>I'm building a project that will launch a service running on localhost. That service needs to be able to talk to a localized, embedded database. Basically I'll be submitting REST requests to that service, and that service will then do something with a local database - saved to local disk for privacy and other project reasons - and then do something else.</p>
<p>Anyway, I wanted to use SQLite, but the problem is that there's CGO involved there with all the sqlite implementations I've seen. I need to be able to cross compile this and run it on Windows as well as OS X and Linux, and with CGO being a limitation, even though I can compile it in 32-bit mode, I feel like that's just asking for trouble down the line. Not to mention, compiling it for Windows looks like one hell of a challenge.</p>
<p>So two questions for my fellow gophers out there:</p>
<ol>
<li>Is there a SQLite or other SQL-like (with index and transaction support) embeddable golang DB out there I can use that has no CGO?</li>
<li>If not, what would you recommend? I prefer to use SQL or at the very least, something ACID-compliant. Can't risk losing data or having info out of sync.</li>
</ol>
<p>Much appreciated, all. Thank you.</p>
<p>EDIT: I should also say that if I can't find something SQL-based, I'm okay with "NoSQL" as long as the language/DB supports ad-hoc queries like SQL does. I'm also OK with building my own indexes based on what I need, kind of like you'd do with Redis. (Only problem is I don't see a way to build and run Redis from within Go, nor do I see a distributable Redis for Windows.)</p>
<p>EDIT 2: I've already experimented with ledisdb, bolt and ql. I'm not a fan of them and really, really want to use SQLite if I can. I'm posting this in case my searching hasn't found something else that the community knows about for whatever reason. But if there just plain IS nothing else, then I guess bolt/ledis/ql it may be. Opinions on those are appreciated.</p>
<hr/>**评论：**<br/><br/>NotEnoughBears: <pre><p>How about BoltDB?</p>
<p>Disclaimer: K/V store, not a true database in the relational sense. Does transactions, don't think it does indexes. </p>
<p><a href="https://github.com/boltdb/bolt">https://github.com/boltdb/bolt</a></p></pre>superduperdud3: <pre><p>This might be, perhaps in combination with ledisdb, my only option. Hoping there's a golang-only sqlite library out there but I might just plain be SOL. Thanks for trying to help!</p></pre>NotEnoughBears: <pre><p>Odds aren't in your favour I'm afraid - there's a large difference in manhours between linking a library and rewriting it from scratch.</p>
<p>Sqlite has years of effort behind it, don't know if there's a strong desire to duplicate that.</p></pre>superduperdud3: <pre><p>Yeah, and re-implementing it definitely bears with it a great deal of risk. Just because the standard is fleshed out well doesn't mean that a re-implemented codebase in another language will be "bulletproof" or all that solid. Agree that odds aren't in my favor!</p>
<p>Are there any other SQL-based embedded DBs you know of beyond SQLite? I've been looking lately at Firebird embedded, but I have to distribute application binaries :/</p></pre>divoxx: <pre><p>What about <a href="https://github.com/google/cayley" rel="nofollow">https://github.com/google/cayley</a> ?</p></pre>superduperdud3: <pre><p>Haven't seen this one before - I'll take a look at it, thanks!</p></pre>barakmich: <pre><p>Cayley author here. I like Bolt, as I hand a lot of the semantics off to the backend. Happy to talk at length about indices and graph data though! </p></pre>superduperdud3: <pre><p>Thanks! Truth be told I've never used a graphing database so this is uncharted territory for me. Most of my experience is in web services with MySQL and/or PostgreSQL, but the concept of graphs and graph-based relations does sound rather intriguing (and enticing). I may ping you privately if I go this route. Much appreciated!</p></pre>peterhellberg: <pre><p>How about ql?</p>
<p><a href="https://github.com/cznic/ql/">https://github.com/cznic/ql/</a></p>
<p>(Or tiedot)</p></pre>superduperdud3: <pre><p>I took a quick look at ql and tiedot already, but thanks for the input!</p></pre>nowayno: <pre><blockquote>
<p>I need to be able to cross compile this and run it on Windows as well as OS X and Linux, and with CGO being a limitation, even though I can compile it in 32-bit mode, I feel like that's just asking for trouble down the line. Not to mention, compiling it for Windows looks like one hell of a challenge.</p>
</blockquote>
<p>Can you elaborate on why it's so onerous to use CGO and compile for Windows and OS X? Perhaps it's not as much of a problem as you think, and at any rate I'd be interested to know what the issues are.</p></pre>superduperdud3: <pre><p>The only example I've seen of doing a cross-compile on Linux targeting Windows is here:</p>
<p><a href="http://www.limitlessfx.com/cross-compile-golang-app-for-windows-from-linux.html" rel="nofollow">http://www.limitlessfx.com/cross-compile-golang-app-for-windows-from-linux.html</a></p>
<p>I've used this guy's method once before and it <em>did</em> compile a 32-bit version of the binary including SQLite, although there was a warning message about compiling a 64-bit version, saying that it wasn't possible. </p>
<p>Now, I'm not very familiar with cross-compilation, especially the limitations of doing so on one platform targeting another, and especially in C/C++. With being new to golang, I figure it's better to focus on ONE workflow/toolchain rather than spreading myself thin on learning golang and its idiosyncracies as well as that of g++/gcc and compiling golang AND that stuff together.</p>
<p>Now, if there's a much simpler way to handle this that you can point me at, I'm definitely interested.</p>
<p>Good question here - thanks for asking it.</p></pre>nowayno: <pre><p>After further investigation it looks like it is indeed a hellishly convoluted process (though if you could simplify and automate it, you'd be a hero to many). I've found cross-compilation to be really easy with Go, and I've been using SQLite extensively <strong>on OS X only</strong>, and for some reason it never occurred to me that these two pleasurable experiences would be nigh impossible to combine. Now I'm kind of bummed…</p>
<p>What was it that turned you off with ql? I've never used it, but it seems like if you're using their database/sql driver it would be basically identical to the experience of using the database/sql driver for SQLite (albeit without having the full power of SQLite at your disposal).</p></pre>superduperdud3: <pre><p>Good question. Basically, the QL docs say (copy/pasta):</p>
<blockquote>
<p>QL is a SQL-like language. It is less complex and less powerful than SQL (whichever specification SQL is considered to be).</p>
</blockquote>
<p>The problem here, for me, is an unknown. I don't know how QL differs, specifically, from other SQL databases. I don't know what features it's lacking that I may need through the life of the project, and I really don't want to make the mistake of going with a data store that I'll have to distribute an "upgrade" for later on to migrate data out of one and into another.</p></pre>pollodelamuerte: <pre><p>The ngrok dude talks a lot about building cross platform tools for go. He's done some talks about it, though it mostly boils down to "build on target platform for target platform". So maybe just roll with some VMs that are set up with GCC and all that business.</p>
<p>You might be able to get some free Windows VMs from Microsoft that are used for browser testing. Perhaps you can use those to try it out? Though I heard they have timers in them so they shut down after a while.</p></pre>superduperdud3: <pre><p>I've got a Windows 8.1x64 host I could build on, but I have -no idea- how to build CGO binaries on Windows. Though I'm sure that's traveled territory by now so I can do the google. ;-) I appreciate the input here, though - thank you!</p></pre>anoland: <pre><p>Perhaps reconsider the embedded requirement? SQLite binaries already exist for windows. Your REST server could just connect to that as the backend data store.</p>
<p>I'm guessing you really want to minimize your installation steps, but that may be untenable considering your goals.</p></pre>superduperdud3: <pre><p>I've thought through this as well, but I don't know for sure how to distribute the application and installer such that it'll have the right binaries together on Windows and register it as a service on startup, etc. However, maybe you're right - perhaps I need to get off my posterior and look that up anyway. Thanks man.</p></pre>THEHIPP0: <pre><p>The problem with SQLite is, that there isn't a protocol the driver needs to implement. Since SQLite operates only locally it would be required to reimplement everything from SQLite in Go to get a pure cgo free solution.</p></pre>
