Harlequin: SQL IDE for Your Terminal | Hacker News Reader

Harlequin: SQL IDE for Your Terminal

github.com

183 pointsjzombie85 comments

Author here. Thanks for more love for Harlequin. I’ll be checking back and responding to feedback and questions for the next few hours.

Looks super impression. Congrats.

A few questions ...

a. what caused you to start working this?

b. any particular reason why you chose to implement it the way you did (e.g. I see you use Python + Textual as opposed to something like https://charm.sh/libs/)

c. any major functionality you feel it's missing?

d. any limitations (e.g. doesn't work with Oracle?)

e. any reason why someone should not use it?

Thanks in advance.

A. I was using the DuckDB CLI and kept hitting walls on analyses. Had a shower thought of “I wonder if anyone has used Textual for a DuckDB client” and decided to build one myself. B. This uses Textual, a python framework for TUIs. Python is my language of choice. C. Hoping for more db adapters soon. Canceling queries is a missing piece I have yet to figure out E. Maybe if you don’t use Python apps and do have another sql client you really like.

Is there a way to order the list of tables in the left hand pane?

Not yet. What order would you like to see?

Alphabetically would be all I'm after, as I make use of psql's partition feature. Keeping all the partitions in a logical order would help me out.

https://harlequin.sh/

There was a Show HN: from the author and this thread and discussion last year:

https://news.ycombinator.com/item?id=37588526

Thanks! Macroexpanded:

Harlequin: DuckDB IDE for the terminal - https://news.ycombinator.com/item?id=37588526 - Sept 2023 (58 comments)

This is a beautiful homepage.

There are also other interesting collections of TUI terminal tools like harlequin here as well:

https://terminaltrove.com/

harlequin is also featured there as a tool of the week on that site.

Wow, I had no idea. Thanks!

Huh, just found this db tui as well via that site: https://terminaltrove.com/gobang/

I would like to put in a vote for k9s, which is also on the list at Terminal Trove. [0] It's the most convenient tool I've ever found for Kubernetes management. Based on that experience I'll definitely be checking out Harlequin.

[0] https://k9scli.io/

The horizontal scroll animation on the query results table is fascinating. Never seen animations like that in a TUI app.

https://textual.textualize.io/

That's impressive! Anyone know if there are similar libraries available for other languages?

I like this one for .NET https://github.com/spectreconsole/spectre.console which I found in this list https://github.com/shadawck/awesome-cli-frameworks.

https://github.com/charmbracelet/bubbletea is a nice TUI framework for Go.

Harlequin has been on my "to investigate" list since it popped up on hn a few weeks/months ago. I still need to experiment with it a bit more, but I had been thinking of building a some tragic equivalent to this, and now I don't have to :)

The HN hive mind is amusing as I came here to get to comment this exact post. It looks really interesting, and I'm also tired of giving up so much memory for just a SQL GUI tool.

I have been looking for a nice SQL TUI and this looks like it. Will give it a try. Thank you.

pspg is a pager intended to be used with SQL command line clients. It was originally created for Postgres (hence the name), but also works with MySQL and others

https://github.com/okbob/pspg

Every time I notice something is a Python codebase I feel a letdown as it means it will likely break some other Python project from someone else I have on my dev machine which I may not have touched in a while but which I will find got silently broken when I most need it

Especially if it's a nice TUI app like this looks

EDIT: Guys, in my experience, virtual environments do not fix this problem in all cases. At least, not sufficiently for me (after getting used to Nix's guarantees, for example). Not to mention, there's multiple ways/attempts at creating and working with virtual environments: https://twitter.com/pmarreck/status/1735363908515295253). See below comment.

Install using pipx to avoid that. (or virtualenvs directly if you don't mind getting your hands dirty)

see my response to your sibling comment by whalesalad.

While I do like pipx, and am a diehard Python fan, if the interpreter used to install the project changes, I still have to reinstall the project, which is annoying.

I suppose I could get around that by installing a Python interpreter outside of brew, and only use that for packages.

This is the problem that 'venv' (virtual environments) was designed to solve.

You can run pip in an isolated virtual environment, in user mode (not as root) - see https://gist.github.com/saurabhshri/46e4069164b87a708b39d947...

See my sibling response(s). Also this comment criticizing the solution in that link you gave me:

https://gist.github.com/saurabhshri/46e4069164b87a708b39d947...

every project you have should be in a virtual environment. it is not hard. https://docs.python.org/3.12/library/venv.html

    python -m venv ~/my-venvs/<name>

    source ~/my-venvs/name/bin/activate

    pip install <package>

but stuff like this would usually get installed globally, and your projects would instead have a venv.

personally my favorite tool is pyenv, which allows you to have many versions of python on your machine as well as many virtualenv (which are assigned to any version you have installed)

then it is as simple as

    pyenv virtualenv <version> <name>
    pyenv virtualenv 3.11.1 xyz

and to activate

    pyenv activate xyz

this allows you to keep every project you have isolated not only to the packages required to run it, but also the python version required.

I work on a handful of projects that run on 3.10, 3.11 and 3.12. Each has their own independent python version, and within that version they also have their own python packages (pip environment).

At the end of the day these are simply directories on disk.

> every project you have should be in a virtual environment

It's like ye-olden days. Now we can go back to static linking and bundling everything in jar files and call it a win!

Yeah. I've heard this same comment before in different forms from "Python apologists" about a dozen times. In practice it's still a lot of hair-pulling, because your entire comment assumes that EVERY Python project is already doing things exactly this way and hasn't screwed up a single part of it: https://twitter.com/pmarreck/status/1735363908515295253

but also...

> but stuff like this would usually get installed globally

well, you just killed (apparently unknowingly?) your whole argument right there, because globals are bad and absolutely not project-specific and absolutely do cause compatibility issues between different Python projects

If you ever come around to Nix, it takes care of this problem for good (as in, it guarantees that you will never have 2 projects that step on each other), across every ecosystem, not just Python's. Unfortunately, I don't see very many Python projects at all that contain a flake.nix file, which is a damn shame, because it would cause people like me to hate Python just a tiny bit less

Hair pulling? It's the most barebones unix thing you can imagine. If you understand unix principles, you can use virtual environments and python.

It used to be hard. A global site-packages or dist-packages dir is hard. Conda and all those tools make it worse.

A virtualenv is a directory. It contains a copy of Python and everything needed.

You don't even need to activate it. You can simply use the binaries that exist in those directories.

It's literally this simple:

    $ python -m venv pmarreck
    $ pmarreck/bin/python --version
    Python 3.10.12
    $ pmarreck/bin/pip install harlequin
    Collecting harlequin
      Downloading harlequin-1.8.0-py3-none-any.whl (61 kB)
        ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 61.5/61.5 kB 1.2 MB/s eta 0:00:00
    ...
    Successfully installed MarkupSafe-2.1.3 click-8.1.7 duckdb-0.9.2 harlequin-1.8.0 jinja2-3.1.2 linkify-it-py-2.0.2 markdown-it-py-3.0.0 mdit-py-plugins-0.4.0 mdurl-0.1.2 numpy-1.26.3 platformdirs-3.11.0 prompt_toolkit-3.0.36 pyarrow-14.0.2 pygments-2.17.2 pyperclip-1.8.2 questionary-2.0.1 rich-13.7.0 rich-click-1.7.3 shandy-sqlfmt-0.21.1 textual-0.46.0 textual-fastdatatable-0.5.0 textual-textarea-0.9.5 tomli-2.0.1 tomlkit-0.12.3 tqdm-4.66.1 tree-sitter-0.20.4 tree_sitter_languages-1.9.1 typing-extensions-4.9.0 uc-micro-py-1.0.2 wcwidth-0.2.12

    $ pmarreck/bin/harlequin

Boom, the tool launched immediately. No conflicts with anything else. When I am done, `rm -rf ~/pmarreck`, done.

I did all of this in my home directory.

It literally cannot get easier than this.

And this works with every existing Python project out there? What about `requirements.txt` projects?

requirements.txt is just a list of packages for pip. It doesn't even need to be called requirements.txt, it could be called poopoopeepee.txt. That name is just a convention.

You could do `for line in requirements.txt, pip install <line>`. They are ostensibly the same. It is not a magical lockfile. It is unix. It is just a list if packages. If you are in a virtualenv, you will be fine.

either activate the venv,

    source venv_directory/bin/activate
    pip install -r requirements.txt

or, skip the convenience and use the binary directly:

    venv_directory/bin/pip install -r requirements.txt

virtualenv activation just sets the $PATH to refer to those binaries. you can use them directly.

the production deployment for my core python app lives in /srv/app, the venv lives in /srv/venv

To update packages on the system, it is as simple as

   cd /srv/app
   /srv/venv/bin/pip install -r requirements.txt

Then to invoke this with the correct runtime, it is as easy as

   /srv/venv/bin/gunicorn ...

In this example I am running the gunicorn application server. This is running the specific gunicorn version installed into my virtualenv.

The name `/srv/venv` is my decision. You can call that whatever you want and put it wherever you want. For instance, if you have two projects called application-foo and application-bar, you can have the following:

    /srv/application-foo/app - the codebase (ie, the github repo)
    /srv/application-foo/venv - the corresponding virtualenv
    /srv/application-bar/app
    /srv/application-bar/venv

Some people will even put their venv dir inside of their source tree and exclude it from git (add to .gitignore), but I do not like this approach because my deployments destroy the app dir and unzip the build into that location on each deploy.

I cannot speak for every python-based project (distinction from pip package) out there. A lot of people do not know what they are doing, open source is literally all the rope to hang yourself with. Anything is possible, and people without engineering experience will glue things together without understanding how they work.

If you are installing something via pip, then yes, you can create N virtualenvs and use them however you want. They are 100% isolated environments.

If you are using homebrew, apt-get, dnf/yum, arch etc... then those are going to obviously vary from distro to distro and that is outside the scope of this discussion.

I try to stick to Python's native tools as much as possible. Using a distribution package is going to cause issues, for sure. IE, don't install `apt-get install python-pil`, use a virtual environment and `pip install PIL`

alright, I will bookmark this and try this next time I want to play with a python project.

OK, how would I include all of these under the same PATH regime?

So for example say I want to run this project from a commandline location elsewhere... I'd only be able to have one venv activated at the same time in the same session, right?

I guess that's part of my issue with this. I want to be able to access 10 different Python projects' commands from the same command line at any time.

To access 10 different commands at the same time, that is tricky but definitely doable.

First thing that comes to mind, you can use aliases.

To keep it simple, lets use 3 examples instead of 10: harlequin (this project), pgcli (https://www.pgcli.com/) and httpx (https://www.python-httpx.org/)

Setup a main home for all your venvs:

    cd ~
    mkdir venvs

Go into this dir, and create your venvs and install the packages

    cd venvs
    python -m venv harlequin
    ~/venvs/harlequin/bin/pip install harlequin

Now this binary is available at

    $ ~/venvs/harlequin/bin/harlequin

Repeat for the rest

    cd ~/venvs
    python -m venv pgcli
    ~/venvs/pgcli/bin/pip install pgcli

    cd ~/venvs
    python -m venv httpx
    ~/venvs/pgcli/bin/pip install httpx

Wash, rinse, repeat. Now you have all these binaries available and can alias them

    alias harlequin="~/venvs/harlequin/bin/harlequin"
    alias pgcli="~/venvs/pgcli/bin/pgcli"
    alias httpx="~/venvs/httpx/bin/httpx"

This is a pain in the ass though and usually simple CLI tools like this do not collide with each other. So that is why I say install globally, or install into your "global junk drawer" virtualenv.

Meanwhile, for actual projects that you are developing on, those would have their own isolated venv.

I have a junk drawer venv where I install tools like this. If something goes wrong, it is as simple as rm -rf the venv and make a new one. And then I have isolated ones for each of the actual systems I maintain. Again, I use pyenv for this to make it a little easier to manage in conjunction with their specific python versions such that I do not ever interact with my distribution's Python. This is cross platform so it works across mac, linux etc. Very easy workflow, isolated, safe, can get blown away and recreated in a heartbeat.

Sounds like something https://www.gnu.org/software/stow/ could help with.

You know, at this point in the complexity story, you're literally at (or beyond) the level of Nix complexity which is the very solution that everyone who engages with this level of tooling seems to be trying to avoid, and since Nix solves this problem already definitively without having to jump through all these hoops, why don't Python projects just use Nix? Then they could all be colocated on the same machine and all be accessible from the same PATH and all have their specific dependencies none of which would ever collide with each other!

Like, you're LITERALLY making a FANTASTIC argument for Nix usage in the Python ecosystem, here. In fact I'm going to bookmark this conversation now because of how ridiculously complicated your answer is compared to just using Nix.

Here's the Nix whitepaper. It's 14 pages or so. Read it on your next lunch break.

https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf

It works for installing dependencies from Pip, so yes, unless that Python project is doing something bizarre that it shouldn't be doing.

It's functionally identical to node_modules or Ruby Bundler or Perl local::lib.

It's so weird to me that people continue to hate Python for a problem that literally every programming language has had since shared libraries were invented.

Your Tweet shows that you don't actually know what these tools do. There's not much overlap in functionality between Pyenv, Tox, and Poetry, for example.

Also, nobody active in the Python community will argue that there's 1 correct way to do packaging. That's a serious straw man.

Fortunately, none of those tools you mentioned other than venv are actually required to run Python applications, and there are in fact exactly 2 recommended ways to install Python applications:

1) Use your system's package manager

2) Use a venv, either manually (as shown in the sibling comment) or using the Pipx tool, which just creates venvs for you.

All of the other tools you mentioned (except for Pyenv) represent ~20 years of active development and iteration on how to manage projects and build packages for distribution, and end-users shouldn't even have to be aware of their existence. And Pyenv is just Rbenv but for Python.

As I've pointed out elsewhere, this is exactly the same situation as with literally every other programming language that doesn't generate standalone executables, and is even a problem with those that do, if they rely on dynamic linking. The special ire towards Python in this case is neither warranted nor valid.

Your pinned post on Twitter is predicated on double standards and lack of basic understanding of the tools you're criticizing. I'm not sure that's a good way to represent oneself.

> Your pinned post on Twitter is predicated on double standards and lack of basic understanding of the tools you're criticizing

If it means that I get to see less Python, then I guess... Mission accomplished? LOL

My first, second and tenth experiences with Python were all negative. Everything from trying to exit the REPL the first time I used it and getting chastised for doing it wrong (which meant that it knew what I was trying to do, and instead of just doing that, decided to be a little snit about it, which is about the jerkiest attitude a tool can take), to the Python 2.x->3.x transition pains, to the significant whitespace, to every project stepping on the dependencies of every other project (you might argue that "I just didn't use venv right" but I did follow every package's installation instructions!), to... Well, just read this, he did a good summary: https://medium.com/nerd-for-tech/python-is-a-bad-programming...

There's literally nothing I like about it. It just seems like a poorly written, older Ruby with a lot of baggage and a minefield of gotchas (except that I like Ruby... or did, before Elixir). Ruby should have absolutely fucking had Python's current market share, and I am 1000% convinced that if it did, everyone would be happier. Whenever Elixir tries to eat Python's lunch (like in the ML space which it's doing now), a part of me is as glad as a puppy. The language, despite its ubiquity, absolutely sucks in my mind, is not only a terrible introduction to programming for newbs but also likely an annoying language to work in, and the people who don't see it HAVE to be blind. That is the only conclusion I can come to, and I'm entitled to my opinion, strong as it is.

Next you're going to say that it is unprofessional to have such strong feelings about code and languages. To that I say: So what, dude. I care. Caring means having very positive feelings about the design decisions behind languages, or very negative feelings about the same. (I don't like Go, either. Python's basically a step above PHP on the "tech I want to minimize my time to zero with" department.)

I made a simple CLI wrapper that automates this, like Poetry does, except my wrapper uses pip.

https://github.com/jzombie/pipper

Have you seen Pipx or its predecessor Pipsi?

Although your tool looks more like Virtualenvwrapper.

It's good to have other options of course (and yours looks nice), but it's also good to at least make a case for improvement over what's already out there.

Thank you.

I have, actually (though not Pipsi). Some others have commented on that and lead me to them.

Part of the "fun" of it was just doing it, I guess, and knowing exactly what went into it. Just a few lines of Bash, really.

His attitude is very Pythonic. That's another thing I didn't like. Other languages let you write whatever you want (maybe to a fault, but still) and support you. This guy's all like "Python has venv and everything else is superfluous so why did you write this". Sigh.

> every project you have should be in a virtual environment. it is not hard.

If it's not hard then why is it not being done by default?

I am not a Python dev and I don't want to be, but when I have to install something via `pip` there's always pain.

"You could learn it", yeah yeah, Python is so special everyone has to learn it even if they don't ever work with it. How about learning from something modern like Go and Rust? `go install github.com/user/tool@latest`, boom, done. `cargo install the_tool`, boom, done.

This isn’t an issue if you use virtual environments. See also pipx for installing isolated Python apps.

See my sibling response(s).

Docker could be an alternative if virtual environments aren't your thing. I'd imagine they would provide a greater degree of isolation, too.

Docker wastes a lot of extra space/resources (disk space, memory, possibly CPU) and can have issues when it comes to needing networking (you start to need a container coordinator). But yes, I've used it in the past. Seems more geared towards server apps than anything else though (although being able to run macOS via Docker is kind of neat).

Wow, this is really good. I can't believe how good terminal app is now.

I did not get a chance to give this a whirl yet but I am excited to do so. I mainly used pgcli but it’s pretty buggy and certainly doesn’t approach IDE status.

Looks great. Is it just DuckDB and SQLite for now? No Postgres?

You can install adapters for pg, MySQL, big query, and trino, with others coming soon. harlequin.sh for more info

Thanks. I must've missed it. I'll take another look.

Question: do people love TUI, because they love being in a terminal?

Or ... is this a movement against application bloat, which has become all to common these days?

EDIT: why the downvotes?

If you develop SQL you need to write code and view tables. A grid with monospace characters is perfectly suitable for that.

But other than that, no, people don't love being in a terminal. It just happens that all open source portable toolkits like qt and gtk do not work via ssh and are in general total abominations for developers and users. The vt100 standard is 45 years old and turned out to be the lowest common denominator to write GUIs for better or worse.

> "if you develop SQL you need to write code and view tables ... [other tools] do not work via ssh"

Are you implying that people only write code inside of a terminal ssh session?

I believe their next sentence took away the need to try to infer anything, and in fact made their point quite clear:

> A grid with monospace characters is perfectly suitable for that.

It doesn't seem like it to me. ISTM that they're implying that most sql tools have a gui component which isn't friendly to running remotely over an ssh session.

I've personally never seen a good experience of display forwarding over ssh.

Of course, most people and tools get around this by tunneling a connection to the database over ssh and running the GUI locally.

I actually like being in the terminal for the most part. The vast majority of GUI applications are a huge disappointment.

> The vt100 standard is 45 years old and turned out to be the lowest common denominator to write GUIs for better or worse.

I would say the web browser is the lowest common denominator

That's assuming you can open up a port on a remote machine, which isn't always the case.

Me. I love being in the terminal. Full-screen nvim with split buffers. If I want a terminal I can spawn it from inside nvim as a new buffer, or use my terminal emulator (kitty)’s native split functionality. I can do git actions without leaving nvim, too.

In case of client-server databases one alternative that works great is to open an ssh tunnel using "ssh -L" and just connect using gui tool to it.

I'm not excited about it being a TUI, I'm just excited because it looks reasonable and I haven't found a macOS SQL client for writing queries that I was excited about yet

I like TUI because it usually works nicely with multiplexer like zellij or tmux. Open a new pane or tab where you can open a new set of TUI apps.

Like have Helix or Nvim open, but you want to quickly check your database queries code changes. You can just open a new tab run the this sql IDE, fire off some queries check the result if it matches go back to coding new features. If not change the code, check queries again etc etc.

Speaking for myself, it wasn't a "movement against application bloat" so much as a "frustrated response to these darn bloated applications." There wasn't anything ideological about it, I literally ran out of memory a few times when using VSCode. The important thing is that editing plain text works perfectly well in a terminal, whereas you need a modern GUI for most other business-related software.

I switched to emacs during the pandemic because of Zoom and Slack (along with my horrible browser habits). VSCode is pretty reasonable on resources compared to many Electron apps, and I slightly prefer it to emacs in terms of overall experience. But emacs is also good, and there were just too many Zoom calls where my computer ran out of memory, with VSCode having a glaringly high footprint. I think at the time its terminal emulator was either excessively inefficient, or it had a specific resource leak. So maybe things have gotten better, but I've stuck with emacs regardless.

These days I can let a few dozen unread tabs in Firefox fill in the extra ~1GB of memory VSCode was formerly occupying :)

Another advantage is that TUI apps can be easily used over SSH.

I originally wrote this because sometimes a CLI or TUI is just super convenient. I used to use the DuckDB and Sqlite CLIs a lot, but was frustrated by their limitations, especially for doing data analysis work (my background).

I do a lot of work with SQLite, and I do sometimes use one of the GUI clients (specifically sqlitebrowser.org). However, I mostly use the command line client that comes with SQLite, not because of how many features it has (not a lot) but because I use Bash and everything that comes with it, across various sessions managed with Tmux, as part of what I do with SQLite. It’s the same reason I usually use Vim in a terminal session instead of the GUI version. Using the GUI version means stepping away from a lot of my best tools.

They are very convenient when I work on remote servers over ssh, even if it's just my server at home. Programs I use regularly (no specific order):

vim ncdu nnn mqqtui htop gitui tmux lnav lazydocker ctop

1. I occasionally have to browse databases through SSH. 2. The CLI / TUI apps take less memory. 3. They also don't lag and lag is something I am absolutely sick of. 4. Easy to build habits in terms of blind keyboard pressing (very much like cashiers on the older DOS keyboard-only software in retail shops; you just know where everything is and are times more productive).

For those who prefer GUI apps, dbnet is an option to serve via HTTP. Run it remote side, access in the browser.

https://github.com/dbnet-io/dbnet

Suggestion: under "works with your database" consider naming the databases rather than only offering a list of icons.

Also seems to be a bit of hubris to claim a SQL IDE "works with your database" when SQL Server and Oracle, two of the database products with the largest market share, are not supported (yet?)

Agreed. I found the current connectors in their docs here: https://harlequin.sh/docs/adapters

I’m pretty pumped to try this seeing BigQuery is supported.

> SQL Server and Oracle, two of the database products with the largest market share

Agree on the first point, but is 'market share' - a metric comparing commercial sales revenue which by definition excludes open source software, really that relevant when critiquing a tagline for a FOSS tool implicitly targeting FOSS databases at a time when FOSS dominates?

If this wasn't an MIT licensed project without a single hint of a commercial offering I'd get it, but come on.

It's relevant in that they're prolific databases, so there's a nontrivial chance that a user of one of them will:

- stumble across the tool

- read that it "works with their database"

- hopefully read the actual list of supported databases

- become disappointed to learn that it does not in fact work with their database

In the case that hopes are not met, the user actually downloads the application and discovers the hard way that it does not work with their database.

So market share does seem relevant to the frequency of disappointment though. Is it going to be a frequent enough occurrence to be worth spending any time doing anything about? I don't know.

Author here. If that disappointment fuels a half day of dev time, anyone who knows Python can just create their own adapter.

> SQL Server and Oracle

Alright so first off, for 90% of SQL Server's existence, Microsoft was openly open-source-hostile, so give me a fucking break with this. Microsoft used to be way worse than even Apple about keeping everything in their ecosystem- at least Apple is built on BSD underpinnings and was therefore also always compatible with POSIX stuff.

Oracle... last I checked on that monstrosity it had about 20 different clients all written at different times for different use cases over the long course of Oracle's history. So, which of these 20 different clients should one write a TUI for?

> give me a fucking break

No we won't :)

https://pypi.org/project/pyodbc/

Fair enough (author here). I just launched support for any databases other than DuckDb and published a guide to create adapters for new dbs. I’m expecting the community to step up here, since I’d rather spend my time adding features to Harlequin. ODBC should be coming shortly. The hard part is honestly just having access to a DB server for testing.

> The hard part is honestly just having access to a DB server for testing.

Fwiw Microsoft SQL server is available as a Linux Docker build:

https://learn.microsoft.com/en-us/sql/linux/quickstart-insta...

Oracle is available as a container and vm:

https://container-registry.oracle.com/ords/f?p=113:4:1173021...

https://github.com/oracle/vagrant-projects

harlequin-odbc was released today. https://harlequin.sh/docs/odbc/index

Looks nice already, but a true "SQL IDE" should also strive for feature parity with existing database frontends like LibreOffice Base, or with old-style MS-DOS/TUI applications for database access which had a similar featureset. Meaning an integrated view of database design, data entry/inspection (with full-screen, form-like views for individual records where appropriate!), custom querying (including a more-or-less seamless integration of QBE and raw SQL) and report generation. Hopefully we're going to see some of this in future releases!

Reply on news.ycombinator.com